* Reizer, Eyal <[email protected]> [170809 10:40]:
> Hi Tony,
>
> Sorry for top posting (mobile...)
> I have verified with system design and the data sheet that every wilink 6/7 chip has a mac address in fuse so probably the board you have (pretty old, right?) has this mac address in fuse. Maybe it was from very early batches? Anyway I see no reason to change it.
> Anyway the calibrator can be used to store a different one into the nvs file that will overide it.
Well clearly at least this one does not have any valid hardware
mac address, the hardware mac address is broken with all zeroes.
It seems that you can easily add a check for empty mac address, no?
And you already showed a version that falls back to a random mac
address.
The fact that is old does not change a thing, we still need to
support it no matter what the data sheet and your system design
says. A fix that breaks other things is not really a fix :)
> I have verified using a couple of com6 modules with an am335x-evm and they had mac addresses read ok.
Sounds like there are multiple variants of the wl12xx
available then.
Regards,
Tony
"Reizer, Eyal" <[email protected]> writes:
>> The fact that is old does not change a thing, we still need to
>> support it no matter what the data sheet and your system design
>> says. A fix that breaks other things is not really a fix :)
>>
>
> Sure, just want to make sure we are not trying to add work around just for
> A couple of faulty devices.
>
>> > I have verified using a couple of com6 modules with an am335x-evm and
>> they had mac addresses read ok.
>>
>> Sounds like there are multiple variants of the wl12xx
>> available then.
>>
> I am trying to find out internally if there is a possibility that there were devices
> Produced in the past where the internal fuses were not programmed with a valid
> Address before being assembled into the modules.
Just a general remark, based on my past experience, you can't really
know what hardware is out there, no matter how someone in the company
claims otherwise. Uncalibrated devices, prototypes and calibration data
broken are all possible and better be preparared for that in the driver.
It's a good idea at least to detect and print a proper error message if
the calibration data is broken. But if the data on the device only
consists of MAC address and nothing else, then I guess using a random
address is fine.
--
Kalle Valo
> >
> > Sorry for top posting (mobile...)
> > I have verified with system design and the data sheet that every wilink=
6/7
> chip has a mac address in fuse so probably the board you have (pretty old=
,
> right?) has this mac address in fuse. Maybe it was from very early batche=
s?
> Anyway I see no reason to change it.
> > Anyway the calibrator can be used to store a different one into the nvs=
file
> that will overide it.
>=20
> Well clearly at least this one does not have any valid hardware
> mac address, the hardware mac address is broken with all zeroes.
>=20
Looks like it is not really all zeros but rather 00:00:00:00:00:01.=20
I wonder if it is just a one board issue or not...
> It seems that you can easily add a check for empty mac address, no?
> And you already showed a version that falls back to a random mac
> address.
>=20
Of course I can add a check for this but need to make sure it=20
is not just one private case.
Do you happen to have another omap3-evm and can check if this is a typical =
case
For the wilink modules that were assembled on this EVM?
I have not seen another module here that showed this issue and want to make=
=20
Sure it is really a common issue before adding additional checks to the ker=
nel.
> The fact that is old does not change a thing, we still need to
> support it no matter what the data sheet and your system design
> says. A fix that breaks other things is not really a fix :)
>=20
Sure, just want to make sure we are not trying to add work around just for
A couple of faulty devices.
> > I have verified using a couple of com6 modules with an am335x-evm and
> they had mac addresses read ok.
>=20
> Sounds like there are multiple variants of the wl12xx
> available then.
>=20
I am trying to find out internally if there is a possibility that there wer=
e devices
Produced in the past where the internal fuses were not programmed with a va=
lid=20
Address before being assembled into the modules.
Best Regards,
Eyal
PiANCj4gT24gVGh1LCBBdWcgMTAsIDIwMTcgYXQgNDozNSBQTSwgUmVpemVyLCBFeWFsIDxleWFs
ckB0aS5jb20+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4gU29ycnkgZm9yIHRvcCBwb3N0aW5nICht
b2JpbGUuLi4pDQo+ID4+ID4gSSBoYXZlIHZlcmlmaWVkIHdpdGggc3lzdGVtIGRlc2lnbiBhbmQg
dGhlIGRhdGEgc2hlZXQgdGhhdCBldmVyeSB3aWxpbmsNCj4gNi83DQo+ID4+IGNoaXAgaGFzIGEg
bWFjIGFkZHJlc3MgaW4gZnVzZSBzbyBwcm9iYWJseSB0aGUgYm9hcmQgeW91IGhhdmUgKHByZXR0
eSBvbGQsDQo+ID4+IHJpZ2h0PykgaGFzIHRoaXMgbWFjIGFkZHJlc3MgaW4gZnVzZS4gTWF5YmUg
aXQgd2FzIGZyb20gdmVyeSBlYXJseQ0KPiBiYXRjaGVzPw0KPiA+PiBBbnl3YXkgSSBzZWUgbm8g
cmVhc29uIHRvIGNoYW5nZSBpdC4NCj4gPj4gPiBBbnl3YXkgdGhlIGNhbGlicmF0b3IgY2FuIGJl
IHVzZWQgdG8gc3RvcmUgYSBkaWZmZXJlbnQgb25lIGludG8gdGhlIG52cw0KPiBmaWxlDQo+ID4+
IHRoYXQgd2lsbCBvdmVyaWRlIGl0Lg0KPiA+Pg0KPiA+PiBXZWxsIGNsZWFybHkgYXQgbGVhc3Qg
dGhpcyBvbmUgZG9lcyBub3QgaGF2ZSBhbnkgdmFsaWQgaGFyZHdhcmUNCj4gPj4gbWFjIGFkZHJl
c3MsIHRoZSBoYXJkd2FyZSBtYWMgYWRkcmVzcyBpcyBicm9rZW4gd2l0aCBhbGwgemVyb2VzLg0K
PiA+Pg0KPiA+DQo+ID4gTG9va3MgbGlrZSBpdCBpcyBub3QgcmVhbGx5IGFsbCB6ZXJvcyBidXQg
cmF0aGVyIDAwOjAwOjAwOjAwOjAwOjAxLg0KPiA+IEkgd29uZGVyIGlmIGl0IGlzIGp1c3QgYSBv
bmUgYm9hcmQgaXNzdWUgb3Igbm90Li4uDQo+IA0KPiBJdCdzIDAwOjAwOjAwOjAwOjAwOjAxIGJl
Y2F1c2UgeW91ciBjb2RlIGFkZHMgMSB0byBpdC4NCj4gDQpZb3UgYXJlIHJpZ2h0IG9mIGNvdXJz
ZSENCkkgc2F3IGl0IGFzIHdlbGwgYWZ0ZXIgc2VuZGluZyBteSBwcmV2aW91cyByZXBseS4NCg0K
QmVzdCBSZWdhcmRzLA0KRXlhbA0K
>=20
> >> The fact that is old does not change a thing, we still need to
> >> support it no matter what the data sheet and your system design
> >> says. A fix that breaks other things is not really a fix :)
> >>
> >
> > Sure, just want to make sure we are not trying to add work around just =
for
> > A couple of faulty devices.
> >
> >> > I have verified using a couple of com6 modules with an am335x-evm an=
d
> >> they had mac addresses read ok.
> >>
> >> Sounds like there are multiple variants of the wl12xx
> >> available then.
> >>
> > I am trying to find out internally if there is a possibility that there=
were
> devices
> > Produced in the past where the internal fuses were not programmed with
> a valid
> > Address before being assembled into the modules.
>=20
> Just a general remark, based on my past experience, you can't really
> know what hardware is out there, no matter how someone in the company
> claims otherwise. Uncalibrated devices, prototypes and calibration data
> broken are all possible and better be preparared for that in the driver.
>=20
> It's a good idea at least to detect and print a proper error message if
> the calibration data is broken. But if the data on the device only
> consists of MAC address and nothing else, then I guess using a random
> address is fine.
>=20
Understood. I will handle the zero mac address case and use random mac inst=
aed.
Just trying to find out how common it is as it seems strange devices like t=
hat found their way to boards that we shipped to customers.
Best Regards,
Eyal
Hi Eyal,
On Thu, Aug 10, 2017 at 4:35 PM, Reizer, Eyal <[email protected]> wrote:
>> >
>> > Sorry for top posting (mobile...)
>> > I have verified with system design and the data sheet that every wilink 6/7
>> chip has a mac address in fuse so probably the board you have (pretty old,
>> right?) has this mac address in fuse. Maybe it was from very early batches?
>> Anyway I see no reason to change it.
>> > Anyway the calibrator can be used to store a different one into the nvs file
>> that will overide it.
>>
>> Well clearly at least this one does not have any valid hardware
>> mac address, the hardware mac address is broken with all zeroes.
>>
>
> Looks like it is not really all zeros but rather 00:00:00:00:00:01.
> I wonder if it is just a one board issue or not...
It's 00:00:00:00:00:01 because your code adds 1 to it.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/