This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A clue....


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]