[U-Boot-Users] 32 bit alignment

[Robert Schwebel]

Hi Wolfgang, 

On Tue, Feb 04, 2003 at 04:50:11PM +0100, Wolfgang Denk wrote:
> Please point out a specific place in the code where (you think)  this
> happens.  We encountered the problem before on other ARM systems, and
> Robert Kaiser fixed most of these places. We found some more, but now
> the code is working fine on the ARM systems I have here.
> 
> I guess you are using something that we  did  not  test  yet  or  not
> thoroughly  enough.  But  I  cannot accept your statement that "whole
> network code" breaks. It runs fine here ;-)

Hmm, perhaps I'm missing something, isn't too improbable ;-) Here's what
I've found out until now: 

- The board is a PXA250 based custom board with a SMSC91111 LAN chip

- I tried to use the DHCP command. Switched it on in the configuration,
  configured the driver to find the correct base address etc. 

- When I start the "dhcp" command I see this on the server: 

  ----------8<----------8<----------8<----------
  DHCPDISCOVER from 00:05:5d:dd:81:aa via eth0
  DHCPOFFER on 213.252.143.168 to 00:05:5d:dd:81:aa via eth0
  DHCPREQUEST for 213.252.0.0 (213.252.143.165) from 00:05:5d:dd:81:aa via eth0: wrong network.
  DHCPNAK on 213.252.0.0 to 00:05:5d:dd:81:aa via eth0
  ----------8<----------8<----------8<----------

- "no network" is correct seen from the server, as the DHCPREQUEST is
  for 213.252.0.0 which is incorrect. 213.252.143.168 would be correct. 

- I tracked this down by switching on several DEBUG defines in
  net/bootp.c, drivers/smsc91111.c and net/net.c. 

- Result: this is how the DHCPOFFER packet looks like, taken from the
  smc91111.c:print_packet() output:

  ----------8<----------8<----------8<----------
  Receiving Packet
  Packet of length 348 
  0005 5ddd 81aa 0005 5df6 026c 0800 4510 
                                     ^^1^
  014c 0000 0000 1011 de4a d5fc 8fa5 d5fc 
  8fa8 0043 0044 0138 76b9 0201 0600 5de8 
  283b 0000 0000 0000 0000 d5fc 8fa8 d5fc 
                           ^^^^^^^2^ ^^^^
  8fa5 0000 0000 0005 5ddd 81aa 0000 0000 
  ^^3^           
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 0000 0000 0000 0000 0000 
  0000 0000 0000 6382 5363 3501 0236 04d5 
  fc8f a533 0400 001c 2001 04ff ffff f003 
  04d5 fc8f a111 222f 686f 6d65 2f65 6d62 
  6564 6465 642f 7074 7864 6973 742d 302e 
  332e 3135 2f72 6f6f 74ff 7440 
  ----------8<----------8<----------8<----------

  ^^1^: start of IP header
  ^^2^: Your IP Address  
  ^^3^: Server IP Address

- Further analysis showed that when u-boot prepares the DHCPREQUEST
  packet which finally fails it takes the "Your IP Address" from the
  packet shown below. This is done by using a pointer to the DHCP
  payload (bp* in net/bootp.c:DhcpHandler()).

- bp->bp_yiaddr does now point to the beginning of the ^^^^2^ marked
  block, starting with "d5". Unfortunately, the 32 bit aligned longword
  at this address is not equivalent to the "d5fc 8fa8" part, but to the
  "0000 d5fc" sequence (using the 16 bits _before_ the place the pointer
  points to). 

- The result is that the next packet (DHCPREQUEST) asks for an address
  which ends in .0.0. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4