Warning NetReceive(): Make sure packet buffers start on an even address
Hi,
The network layer currently handles packets with c-structures overlayd on the packets.
NetReceive() will fail to correctly parse packets that are not word aligned (at least on ARM cpus).
Just figured that out debugging the enc28j60 driver. Which had no fault except for having the receive packet buffer on an odd address :)
Instead of:
static unsigned char buffer[ENC_MAX_FRM_LEN];
The following works fine:
static unsigned long lbuffer[ENC_MAX_FRM_LEN/4]; #define buffer ((unsigned char *)lbuffer)
Is there a more elegant way of forcing a char array to start on an even address?
Reinhard
Dear "Reinhard Meyer (-VC)",
Quoted 9 lines · In message <[email protected]> you wrote:
Instead of:
static unsigned char buffer[ENC_MAX_FRM_LEN];
The following works fine:
static unsigned long lbuffer[ENC_MAX_FRM_LEN/4]; #define buffer ((unsigned char *)lbuffer)Is there a more elegant way of forcing a char array to start on an even address?
Sure. Use something like
static unsigned char buffer[ENC_MAX_FRM_LEN] __attribute__ ((aligned(4)));
Or, probably even better, use malloc() to allocate the buffer.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for the standard to attempt to constrain the
behavior of code that does not obey the constraints of the standard.
- Doug GwynQuoted 1 line · Wolfgang Denk
static unsigned char buffer[ENC_MAX_FRM_LEN] __attribute__ ((aligned(4)));
Thanks, sometimes the very obvious is hidden behind a large wooden board :)
Quoted 2 lines
Or, probably even better, use
malloc()to allocate the buffer.
For each received packet? Could do that, but its not worth it. Received packets are queued in the 6K RAM of the enc28j60. I'll see if the enc can be made to ignore broadcast packets, otherwise it might get tough either way on a busy Windows network .....
Or are you aware of any need to hand over broadcast packets into NetReceive() ?
Reinhard
-----Original Message-----
From: Reinhard Meyer (-VC) <[email protected]>
Reply-to: reinhard.meyer at emk-elektronik.de
To: Wolfgang Denk <[email protected]>
Cc: u-boot <[email protected]>
Subject: Re: [U-Boot] Warning NetReceive(): Make sure packet buffers start on an even address
Date: Fri, 06 Aug 2010 12:38:58 +0200
Quoted 1 line · Wolfgang Denk
static unsigned char buffer[ENC_MAX_FRM_LEN] __attribute__ ((aligned(4)));
Thanks, sometimes the very obvious is hidden behind a large wooden board :)
Quoted 2 lines
Or, probably even better, use
malloc()to allocate the buffer.
For each received packet? Could do that, but its not worth it. Received packets are queued in the 6K RAM of the enc28j60. I'll see if the enc can be made to ignore broadcast packets, otherwise it might get tough either way on a busy Windows network .....
Or are you aware of any need to hand over broadcast packets into NetReceive() ?
I am stepping into the middle of this, so the following may be totally misguided...
BOOTP/DHCP servers can send broadcast packets. I have just tried this with a Windows DHCP server the the DHCP response was broadcast.
Signature · 3 lines
Chris Isbell Systems Integration Manager, CDSRail Fareham, Hampshire, UK.
Quoted 8 lines · Chris Isbell
Or are you aware of any need to hand over broadcast packets into
NetReceive()?I am stepping into the middle of this, so the following may be totally misguided...
BOOTP/DHCP servers can send broadcast packets. I have just tried this with a Windows DHCP server the the DHCP response was broadcast.
Thanks for the info!
That sounds like typical Windows (%&@#*)....
Duly noted, broadcast reception is configurable by #define now.
Best Regards
Reinhard
Dear "Reinhard Meyer (-VC)",
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 1 line · Wolfgang Denk
static unsigned char buffer[ENC_MAX_FRM_LEN] __attribute__ ((aligned(4)));Thanks, sometimes the very obvious is hidden behind a large wooden board :)
Quoted 1 line
Or, probably even better, use
malloc()to allocate the buffer.For each received packet? Could do that, but its not worth it.
Not for each packet, only for the first one, of course, or when initializing the driver.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Der Horizont vieler Menschen ist ein Kreis mit Radius Null -- und das nennen sie ihren Standpunkt.
Quoted 4 lines · Wolfgang Denk
Dear "Reinhard Meyer (-VC)",
Quoted 1 line · In message <[email protected]> you wrote:
Wolfgang Denk schrieb:
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
static unsigned char buffer[ENC_MAX_FRM_LEN] __attribute__ ((aligned(4)));Thanks, sometimes the very obvious is hidden behind a large wooden board :)
Quoted 1 line
Or, probably even better, use
malloc()to allocate the buffer.For each received packet? Could do that, but its not worth it.
Not for each packet, only for the first one, of course, or when initializing the driver.
Whats the benefit except for probably increased code size?
The only one I see is 1.5k more free RAM as long as the driver is not initialized/used...
Best Regards
Reinhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100806/543d71c4/attachment.vcf
Dear Reinhard Meyer,
Quoted 5 lines · In message <[email protected]> you wrote:
Whats the benefit except for probably increased code size?
The only one I see is 1.5k more free RAM as long as the driver is not initialized/used...
Well, that is a benefit, isn't it? And it should have no negative side-effects either, so why not make use of it?
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The thing is, as you progress in the Craft, you'll learn there is
another rule... When you break rules, break 'em good and hard.
- Terry Pratchett, _Wyrd Sisters_