[ECOS] A clue....

[Chuck McManis]

At 12:09 PM 2/15/2006, Andrew Lunn wrote:
>No. eCos has built the packet to be sent including the source
>address. The chip has just sent a collection of bytes, it was not
>responsible for putting the MAC address into the packet. So what you
>see on the wire tells you nothing about what the chip thinks its
>address is.

Ahhh, I see. That would certainly make sense as a root cause, if the MAC 
didn't think it was seeing its address it wouldn't receive the packets. 
Another test I did last night when I was half asleep was to put (I think, 
its new code of course) the MAC into promiscuous mode. In theory that would 
have forced it to return every packet it saw coming across the network and 
if it wasn't acking its real mac address I believe the switch would have 
left its port in the broadcast domain (can't update its internal spanning 
tree if it doesn't see a successful packet path established)

One of the areas I have started looking into was to see if I fat fingered 
the flag definitions in the receiver descriptors such that "Recieve OK" was 
actually checking "Broadcast Packet" rather than the real receive ok.

Getting back to your observation however, and maybe this is a good one for 
Gary, is there a simple test to prove/disprove that the MAC address is 
valid? Clearly in the banner I read out the contents of offset 0 - 5 and 
print them and give them as the ESA, but in your experience is there 
perhaps some way to "load that value" into the internal state machines? 
(I'm wondering if I would, in theory, have to do a soft reset after loading 
the ESA). Another tack I'll take on this one a bit later on is to disable 
ALL the code that writes the ESA leaving only the one that appears in PAR0 
- PAR5 as the one I report. My theory on that is that the MAC/PHY combo 
does the "right thing" by default on boot up and should correctly configure 
itself with a valid ESA. Then I'll need to figure out a way to cons up a 
packet with that ESA as the destination address to see if the box responds 
to it w/ my driver running. (Like I mentioned earlier, when I boot FreeBSD 
on this target it installs the VR driver and it works fine)

--Chuck 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss