getmac.h/xc oddities about sc_ethernet HOT 14 CLOSED

correction: the compiler DOES not like it:

Creating app_ledtile.xe
.././../../sc_ethernet/module_ethernet/src/server/getmac.xc: Error: Type of symbol ethernet_getmac_otp_indexed has mismatch with previous definition:
.././../../sc_ethernet/module_ethernet/src/server/getmac.xc: Error: found: void ethernet_getmac_otp_indexed( port, out port, port, unsigned char[], unsigned int )
.././src/ethernet/localServer/retrieveMAC/get_mac_addr.xc: Error: previous: void ethernet_getmac_otp_indexed( port, out port, port, signed int[], unsigned int )

from sc_ethernet.

The address is compared inside the code using a word aligned compare, so it passes data back word aligned. that is the reason for the int[] rather than the char[]. I think that the char[] in the XC file is a mistake.

from sc_ethernet.

will fork, repair & pull request ;)
see comment abt. compiler error

from sc_ethernet.

thanks.

from sc_ethernet.

Whoops. See Dave's reply - it sounds like the correct type is array of ints.

from sc_ethernet.

its possible that the API does a byte copy from the word aligned entry to the char aligned one.

this OTP get mac thing was originally going to support layer-3 type routers where there are multiple MAC addresses for a single board. since we have abandoned that for the time being, there is only a need for a single MAC address for any board including ones with multiple ports. hence this indexed and count getmac stuff isn't really that important.

from sc_ethernet.

whoopsala, over my head ;)

perhaps you have seen the changes in my pull request - they seem to solve the issues from the compiler point of view (which is neccessarily the first step to fix it from a functional point of view). I will test it presumably next week (still in the middle of sc_ethernet migration for ap_led_tile).

Are there any automated test which could be used to verify the fix?

from sc_ethernet.

I'm not sure that there is, to test the multiple MAC address part. But the getting a single MAC address just gets entry zero, so if any code at all successfully returns a MAC address without causing an alignment exception, then you can be happy that all is ok.

from sc_ethernet.

Will close this issue after successfully testing it next week (lil' bit too short on time)

from sc_ethernet.

Hi Marcus,

I've had to revert to before your commit. It causes our AVB reference design to error on compile and I haven't time to implement the necessary fixes in all the AVB apps at the moment. Can you implement a fix in your LED repo in the meantime?

from sc_ethernet.

Hi Andy,

No problem. I will keep it in my fork. And try to keep my fork as updated as possible. I will reopen the issue so that we have a reminder. Is that OK?
Then we can see later how can get it into the upstream. I think it should be there.

Marcus

This mail may contain unwanted typos

Am 14.10.2011 um 19:20 schrieb Andy Lucas [email protected]:

Hi Marcus,

I've had to revert to before your commit. It causes our AVB reference design to error on compile and I haven't time to implement the necessary fixes in all the AVB apps at the moment. Can you implement a fix in your LED repo in the meantime?

Reply to this email directly or view it on GitHub:
#10 (comment)

from sc_ethernet.

Yes, great. Will revisit this in the near future.

from sc_ethernet.

is there any progress in applying the changes to the AVB framework?
Still want to get rid of my sc_ethernet fork ;)

from sc_ethernet.

Closing. Now using sc_otp for reading MAC addresses.

from sc_ethernet.