A group dedicated to Pandaboard, a small form factor open-source board based on OMAP4 ARM processor. ()

jmaher | 16 Jun 2012 03:11

Android ICS on Panda and retaining the MAC address across reboots

I am looking to use the Panda boards in large volume for automating software on Android ICS. I have tried the pre built binaries from Linaro as well as building my own kernel, but every time I reboot the Panda board the MAC address is randomly generated. So random in fact that all 6 hex values are random instead of the first 3 being designated for the hardware vendor and the last 3 being random.

I suspect this is because there is no EEPROM on the Panda board.

Does anybody have a solution to this? Maybe there is something on the boards I am overlooking? Maybe there is something in the Android kernel that I am overlooking? I am open to just about anything, with the one requirement being that this is something that doesn't require manually setting it, especially in bootargs or other parameters like that. We really would like to build an image of the OS and tools on the sdcard and replicate that to a couple hundred of these guys and rack them up in a data center.

headers

Mark Olleson | 16 Jun 2012 17:22

Re: Android ICS on Panda and retaining the MAC address across reboots

Are you building a test automation rig?

You are correct - the ethernet driver creates a MAC address randomly and TiWI2 module (WIfi) stores the radio configuration parameters and MAC address in one of the firmware files.

This arrangement is perhaps a bit naughty in that an OEM is supposed to apply for an OUI block and allocate address from it for each device they manufacture. On the other hand, the Pandaboard is clearly marketed as being an evaluation board and not for production use. By all accounts they are a loss-leader, or at best zero profit line as far as TI is concerned. In fact, will DigiKey even supply you Pandaboards in bulk? if not, there are several manufacturers of production-quality System-on-module designs with equivalent functionality.

You can certainly change the MAC address of the ethernet interface from userspace in Linux, and some distros do exactly this in their init scripts to provide persistent MAC addresses. Not sure how you'd do this in Android - but the kernel interfaces to do it will be present. I don't think this works for the WL1271 though.

Do the standard (e.g. non-secure) variants of the OMAP4xxx have on-die serial numbers? The obvious automated solution is to generate MAC addresses based on this (and probably assuming an unallocated OUI).

Another option might be to hang an I2C EEPROM off one of the I2C busses - available on expansion headers.

if you want to set the wl1271 MAC Address, you need the calibrate tool in the ti-utils package. You may be able to get this to run on your dev host when building SD card images.

Incidentally, SD cards are not a terribly robust boot medium for production use. The block-allocation and wear levelling algorithms on some cards are flakey, and will occasionally leave you with recoverable filing systems. Consider network booting the root filing system and kernel - although you'll need to crack the persistent MAC Address problem before there's any chance of this working - in both the kernel and boot-loader. Both u-boot and Barebox are capable of TFTP.

On 16 June 2012 02:11, jmaher <joel.maher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I am looking to use the Panda boards in large volume for automating software on Android ICS. I have tried the pre built binaries from Linaro as well as building my own kernel, but every time I reboot the Panda board the MAC address is randomly generated. So random in fact that all 6 hex values are random instead of the first 3 being designated for the hardware vendor and the last 3 being random.

I suspect this is because there is no EEPROM on the Panda board.

Does anybody have a solution to this? Maybe there is something on the boards I am overlooking? Maybe there is something in the Android kernel that I am overlooking? I am open to just about anything, with the one requirement being that this is something that doesn't require manually setting it, especially in bootargs or other parameters like that. We really would like to build an image of the OS and tools on the sdcard and replicate that to a couple hundred of these guys and rack them up in a data center.

headers

jmaher | 18 Jun 2012 13:25

Re: Android ICS on Panda and retaining the MAC address across reboots

Yes, we are building a test automation rig and using the wired ethernet is one of the advantages of the pandaboard over many other boards.

Thanks for the tips on this, all great ideas.

As for the booting of the OS and sdcards, that is good to know about tftp. Now if I can get tftp to have a stable mac address, then I could really make something cool.

Do you have a specific recommendation for an sdcard that might be more stable over time?

Thanks,
Joel

On Saturday, June 16, 2012 11:22:29 AM UTC-4, Mark Olleson wrote:

Are you building a test automation rig?

You are correct - the ethernet driver creates a MAC address randomly and TiWI2 module (WIfi) stores the radio configuration parameters and MAC address in one of the firmware files.

This arrangement is perhaps a bit naughty in that an OEM is supposed to apply for an OUI block and allocate address from it for each device they manufacture. On the other hand, the Pandaboard is clearly marketed as being an evaluation board and not for production use. By all accounts they are a loss-leader, or at best zero profit line as far as TI is concerned. In fact, will DigiKey even supply you Pandaboards in bulk? if not, there are several manufacturers of production-quality System-on-module designs with equivalent functionality.

You can certainly change the MAC address of the ethernet interface from userspace in Linux, and some distros do exactly this in their init scripts to provide persistent MAC addresses. Not sure how you'd do this in Android - but the kernel interfaces to do it will be present. I don't think this works for the WL1271 though.

Do the standard (e.g. non-secure) variants of the OMAP4xxx have on-die serial numbers? The obvious automated solution is to generate MAC addresses based on this (and probably assuming an unallocated OUI).

Another option might be to hang an I2C EEPROM off one of the I2C busses - available on expansion headers.

if you want to set the wl1271 MAC Address, you need the calibrate tool in the ti-utils package. You may be able to get this to run on your dev host when building SD card images.

Incidentally, SD cards are not a terribly robust boot medium for production use. The block-allocation and wear levelling algorithms on some cards are flakey, and will occasionally leave you with recoverable filing systems. Consider network booting the root filing system and kernel - although you'll need to crack the persistent MAC Address problem before there's any chance of this working - in both the kernel and boot-loader. Both u-boot and Barebox are capable of TFTP.

On 16 June 2012 02:11, jmaher <joel.maher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I am looking to use the Panda boards in large volume for automating software on Android ICS. I have tried the pre built binaries from Linaro as well as building my own kernel, but every time I reboot the Panda board the MAC address is randomly generated. So random in fact that all 6 hex values are random instead of the first 3 being designated for the hardware vendor and the last 3 being random.

I suspect this is because there is no EEPROM on the Panda board.

Does anybody have a solution to this? Maybe there is something on the boards I am overlooking? Maybe there is something in the Android kernel that I am overlooking? I am open to just about anything, with the one requirement being that this is something that doesn't require manually setting it, especially in bootargs or other parameters like that. We really would like to build an image of the OS and tools on the sdcard and replicate that to a couple hundred of these guys and rack them up in a data center.

headers

Pavol Cupka | 1 Aug 2012 10:42

Re: Android ICS on Panda and retaining the MAC address across reboots

http://www.bisect.de/downloads/patches/kernel/20120131.1/0001-smsc95xx-add-macaddr-module-parameter.patch

On Mon, Jun 18, 2012 at 1:25 PM, jmaher <joel.maher@...> wrote:
> Yes, we are building a test automation rig and using the wired ethernet is
> one of the advantages of the pandaboard over many other boards.
>
> Thanks for the tips on this, all great ideas.
>
> As for the booting of the OS and sdcards, that is good to know about tftp.
> Now if I can get tftp to have a stable mac address, then I could really make
> something cool.
>
> Do you have a specific recommendation for an sdcard that might be more
> stable over time?
>
> Thanks,
> Joel
>
>
> On Saturday, June 16, 2012 11:22:29 AM UTC-4, Mark Olleson wrote:
>>
>> Are you building a test automation rig?
>>
>> You are correct  - the ethernet driver creates a MAC address randomly and
>> TiWI2 module (WIfi) stores the radio configuration parameters and MAC
>> address in one of the firmware files.
>>
>> This arrangement is perhaps a bit naughty in that an OEM is supposed to
>> apply for an OUI block and allocate address from it for each device they
>> manufacture.  On the other hand, the Pandaboard is clearly marketed as being
>> an evaluation board and not for production use.   By all accounts they are a
>> loss-leader, or at best zero profit line as far as TI is concerned.  In
>> fact, will DigiKey even supply you Pandaboards in bulk?  if not, there are
>> several manufacturers of production-quality System-on-module designs with
>> equivalent functionality.
>>
>> You can certainly change the MAC address of the ethernet interface from
>> userspace in Linux, and some distros do exactly this in their init scripts
>> to provide persistent MAC addresses.  Not sure how you'd do this in Android
>> - but the kernel interfaces to do it will be present.   I don't think this
>> works for the WL1271 though.
>>
>> Do the standard (e.g. non-secure) variants of the OMAP4xxx have on-die
>> serial numbers? The obvious automated solution is to generate MAC addresses
>> based on this (and probably assuming an unallocated OUI).
>>
>> Another option might be to hang an I2C EEPROM off one of the I2C busses -
>> available on expansion headers.
>>
>> if you want to set the wl1271 MAC Address, you need the calibrate tool in
>> the ti-utils package.  You may be able to get this to run on your dev host
>> when building SD card images.
>>
>> Incidentally, SD cards are not a terribly robust boot medium for
>> production use.  The block-allocation and wear levelling algorithms on some
>> cards are flakey, and will occasionally leave you with recoverable filing
>> systems. Consider network booting the root filing system and kernel -
>> although you'll need to crack the persistent MAC Address problem before
>> there's any chance of this working - in both the kernel and boot-loader.
>> Both  u-boot and Barebox are capable of TFTP.
>>
>>
>>
>> On 16 June 2012 02:11, jmaher <joel.maher@...> wrote:
>>>
>>> I am looking to use the Panda boards in large volume for automating
>>> software on Android ICS.  I have tried the pre built binaries from Linaro as
>>> well as building my own kernel, but every time I reboot the Panda board the
>>> MAC address is randomly generated.  So random in fact that all 6 hex values
>>> are random instead of the first 3 being designated for the hardware vendor
>>> and the last 3 being random.
>>>
>>> I suspect this is because there is no EEPROM on the Panda board.
>>>
>>> Does anybody have a solution to this?  Maybe there is something on the
>>> boards I am overlooking?  Maybe there is something in the Android kernel
>>> that I am overlooking?  I am open to just about anything, with the one
>>> requirement being that this is something that doesn't require manually
>>> setting it, especially in bootargs or other parameters like that.  We really
>>> would like to build an image of the OS and tools on the sdcard and replicate
>>> that to a couple hundred of these guys and rack them up in a data center.
>>>
>>>
>>
>