On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: > I do not have this behaviour on the Cubieboard2, just on my Cubietruck. > > I thought it was a problem with the F21 build, but today I am working > with F19 remix: > > http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... > > And I keep getting a different MACaddr. This makes it really hard to > use persistant.rules to control things based on MACaddr. > > Is this just my particular Cubietruck? I remember Hans talking about > since there is no eeprom, he has to use SID as the basis for the > MACaddr. > > Is there anyway for me to set the MACaddr. It is eating up all my dhcp > > addresses. There are rules for what constitutes a valid mac address, if yours in invalid the kernel driver will assign you a random one, and then it looks like a new machine every time. You can force the mac address in userland /etc/rc.d/rc.local using /sbin/nameif + /etc/mactab, it's dirty but it will get you out of the hole if it runs before the dhclient action poisons your dhcp server.

If the network driver uses phylib, there is a generic Device Tree name you can use like this inside the ethernet stanza to force it local-mac-address = [ aa bb cc dd ee ff ]; if so, you can think about adding / overriding that DT node in U-Boot before passing to kernel. I sent patches on lkml to improve this a couple of years ago (for Panda, which has no nonvolatile config onboard) by replacing an invalid MAC with computing a consistent per-board MAC from CPU serial ID but The Powers That Be felt it should be fixed by the distros... which as you see...

W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: > Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back on > 12/26/2013. He supposedly uses the SID for a consistant local scope > MACaddr. I Do get that on my Cubieboard2, but not on my Cubietruck. Hans also told that there was a bunch of Cubie* with pre-production cpus which lacked serial number.

On 09/09/2014 02:41 AM, Hans de Goede wrote: > Hi, > > On 09/09/2014 07:40 AM, Marcin Juszkiewicz wrote: >> W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: >>> Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back on >>> 12/26/2013. He supposedly uses the SID for a consistant local scope >>> MACaddr. I Do get that on my Cubieboard2, but not on my Cubietruck. >> Hans also told that there was a bunch of Cubie* with pre-production cpus >> which lacked serial number. > AFAIK only cubieboard2 and olinuxino-a20-micro suffer from this, the > cubietruck is fine. On machines with an all 0 sid this indeed does not > work. My SIX Cubieboard2 all are fine with a consistant MAC address.

My one Cubietruck keeps coming up with the unique MACaddr. Exact opposite of what you are reporting.

Perhaps there is a rev difference in the shipped nand? In all cases, I never did anything with the nand image, but went right to the SDcard image. I just don't get how to do the nand poking to get something working from it.

Is there any test I can run on my CT?

anyway to set the SID if it is zero?

I am at ITS World Congress in downtown Detroit today, so I can't do any testing until this evening... On 09/09/2014 07:02 AM, Hans de Goede wrote: > Hi, > > On 09/09/2014 12:28 PM, Robert Moskowitz wrote: >> On 09/09/2014 02:41 AM, Hans de Goede wrote: >>> Hi, >>> >>> On 09/09/2014 07:40 AM, Marcin Juszkiewicz wrote: >>>> W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: >>>>> Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back on >>>>> 12/26/2013. He supposedly uses the SID for a consistant local scope >>>>> MACaddr. I Do get that on my Cubieboard2, but not on my Cubietruck. >>>> Hans also told that there was a bunch of Cubie* with pre-production cpus >>>> which lacked serial number. >>> AFAIK only cubieboard2 and olinuxino-a20-micro suffer from this, the >>> cubietruck is fine. On machines with an all 0 sid this indeed does not >>> work. >> My SIX Cubieboard2 all are fine with a consistant MAC address. > Good, then later runs of the cubieboard2 have gotten a proper SID, that is good. > >> My one Cubietruck keeps coming up with the unique MACaddr. Exact opposite of what you are reporting. > Which version of Fedora are you running on your Cubietruck ? Your F19 and last the 9/5 build of F21-minimal. Here is what I do for the F19: http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... xzcat /home/rgm/arm/Fedora-19-a10-armhfp-r3.img.xz > /dev/sdb; sync <reinsert card> /run/media/rgm/uboot/select-board.sh cubieboard2[cubietruck] umount /run/media/rgm/uboot umount /run/media/rgm/rootfs I never saw anything after the R3 release. > > With the respin images the kernel takes care of getting the MAC from the SID, > with the official F-21 images, u-boot needs to do this, and the u-boot included > is (not yet) new enough. hmmm. For cubieboard2, I use your git repo: git clone https://github.com/jwrdegoede/u-boot-sunxi.git cd u-boot-sunxi git checkout -B next origin/next make -j4 CROSS_COMPILE=arm-linux-gnu- Cubieboard2_defconfig make -j4 CROSS_COMPILE=arm-linux-gnu- dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 sync Is there a way to also make a uboot for the cubietruck to update what is on koji?

>> Perhaps there is a rev difference in the shipped nand? In all cases, I never did anything with the nand image, but went right to the SDcard image. I just don't get how to do the nand poking to get something working from it. > The SID is in the SoC, it has nothing to do with the nand. Well that is a start. > >> Is there any test I can run on my CT? > You can dump the sid by hooking up a serial console, and then pressing a > key to interrupt u-boot, then do: > > md 1c23800 4 If I don't have an SDcard in the unit I end up at a sunxi# prompt. Is this the same thing?

> > To get the SID contents, see here for example SID-s : > > http://linux-sunxi.org/SID_Register_Guide > > If this is non-0 on your cubietruck, then you should get a consistent MAC > with the respin images, and you should be able to get a consistent MAC > with F-21 by building (and installing) u-boot from here: > > http://git.denx.de/?p=u-boot.git;a=summary Makes no sense to me. What do I do with this?

OK. back doing some testing. So far all with F19. On 09/09/2014 07:02 AM, Hans de Goede wrote: > Hi, > > On 09/09/2014 12:28 PM, Robert Moskowitz wrote: >> On 09/09/2014 02:41 AM, Hans de Goede wrote: >>> Hi, >>> >>> On 09/09/2014 07:40 AM, Marcin Juszkiewicz wrote: >>>> W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: >>>>> Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back on >>>>> 12/26/2013. He supposedly uses the SID for a consistant local scope >>>>> MACaddr. I Do get that on my Cubieboard2, but not on my Cubietruck. >>>> Hans also told that there was a bunch of Cubie* with pre-production cpus >>>> which lacked serial number. >>> AFAIK only cubieboard2 and olinuxino-a20-micro suffer from this, the >>> cubietruck is fine. On machines with an all 0 sid this indeed does not >>> work. >> My SIX Cubieboard2 all are fine with a consistant MAC address. > Good, then later runs of the cubieboard2 have gotten a proper SID, that is good. > >> My one Cubietruck keeps coming up with the unique MACaddr. Exact opposite of what you are reporting. > Which version of Fedora are you running on your Cubietruck ? > > With the respin images the kernel takes care of getting the MAC from the SID, > with the official F-21 images, u-boot needs to do this, and the u-boot included > is (not yet) new enough. > >> Perhaps there is a rev difference in the shipped nand? In all cases, I never did anything with the nand image, but went right to the SDcard image. I just don't get how to do the nand poking to get something working from it. > The SID is in the SoC, it has nothing to do with the nand. > >> Is there any test I can run on my CT? > You can dump the sid by hooking up a serial console, and then pressing a > key to interrupt u-boot, then do: > > md 1c23800 4 > > To get the SID contents, see here for example SID-s : > > http://linux-sunxi.org/SID_Register_Guide > > If this is non-0 on your cubietruck, then you should get a consistent MAC > with the respin images, Well, I am not. For the Cubietruck. Here is the SID fromthe CT and different MACaddr from a series of boots from the F19 image: md 1c23800 4 01c23800: 165166c1 80485172 49514848 0881e2d7 .fQ.rQH.HHQI.... ea:99:af:e5:2f:5b ea:22:02:c6:83:c8 fe:1d:9a:25:3b:48 Then I switch over to a Cubieboard2, also with F19: md 1c23800 4 01c23800: 165166c4 80485072 56484848 0382c153 .fQ.rPH.HHHVS... 02:c4:03:82:c1:53 I notice with the C2, the MAC is the last word of the SID. But for the CT, I cannot figure it out at all.

I have a bit of other testing to do (VLAN setup), then I will switch to F21 and see if I can get the current uboot for the CT working.

On 09/09/2014 07:12 PM, Hans de Goede wrote: > Hi, > > On 09/09/2014 10:44 PM, Robert Moskowitz wrote: >> OK. back doing some testing. So far all with F19. >> >> On 09/09/2014 07:02 AM, Hans de Goede wrote: >>> Hi, >>> >>> On 09/09/2014 12:28 PM, Robert Moskowitz wrote: >>>> On 09/09/2014 02:41 AM, Hans de Goede wrote: >>>>> Hi, >>>>> >>>>> On 09/09/2014 07:40 AM, Marcin Juszkiewicz wrote: >>>>>> W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: >>>>>>> Read Hans de Goede's post on the F19 and the Allwinner (Cubie) >>>>>>> back on >>>>>>> 12/26/2013. He supposedly uses the SID for a consistant local >>>>>>> scope >>>>>>> MACaddr. I Do get that on my Cubieboard2, but not on my >>>>>>> Cubietruck. >>>>>> Hans also told that there was a bunch of Cubie* with >>>>>> pre-production cpus >>>>>> which lacked serial number. >>>>> AFAIK only cubieboard2 and olinuxino-a20-micro suffer from this, the >>>>> cubietruck is fine. On machines with an all 0 sid this indeed >>>>> does not >>>>> work. >>>> My SIX Cubieboard2 all are fine with a consistant MAC address. >>> Good, then later runs of the cubieboard2 have gotten a proper SID, >>> that is good. >>> >>>> My one Cubietruck keeps coming up with the unique MACaddr. Exact >>>> opposite of what you are reporting. >>> Which version of Fedora are you running on your Cubietruck ? >>> >>> With the respin images the kernel takes care of getting the MAC >>> from the SID, >>> with the official F-21 images, u-boot needs to do this, and the >>> u-boot included >>> is (not yet) new enough. >>> >>>> Perhaps there is a rev difference in the shipped nand? In all >>>> cases, I never did anything with the nand image, but went right to >>>> the SDcard image. I just don't get how to do the nand poking to >>>> get something working from it. >>> The SID is in the SoC, it has nothing to do with the nand. >>> >>>> Is there any test I can run on my CT? >>> You can dump the sid by hooking up a serial console, and then >>> pressing a >>> key to interrupt u-boot, then do: >>> >>> md 1c23800 4 >>> >>> To get the SID contents, see here for example SID-s : >>> >>> http://linux-sunxi.org/SID_Register_Guide >>> >>> If this is non-0 on your cubietruck, then you should get a >>> consistent MAC >>> with the respin images, >> Well, I am not. For the Cubietruck. Here is the SID fromthe CT and >> different MACaddr from a series of boots from the F19 image: >> >> md 1c23800 4 >> >> 01c23800: 165166c1 80485172 49514848 0881e2d7 .fQ.rQH.HHQI.... >> >> ea:99:af:e5:2f:5b >> >> ea:22:02:c6:83:c8 >> >> fe:1d:9a:25:3b:48 >> >> Then I switch over to a Cubieboard2, also with F19: >> >> md 1c23800 4 >> 01c23800: 165166c4 80485072 56484848 0382c153 .fQ.rPH.HHHVS... >> >> 02:c4:03:82:c1:53 >> >> >> I notice with the C2, the MAC is the last word of the SID. But for >> the CT, I cannot figure it out at all. > Ah right, I remember now the kernel code to use the SID for the MAC > in F-19 is > part of the emac driver, and the A20 uses the gmac driver, that is > why it is > not working on the cubietruck with F-19. I thought both are A20 boards. Though the C2 has the 100Mb ethernet, and the CT the 1Gb. > >> I have a bit of other testing to do (VLAN setup), then I will switch >> to F21 and see if I can get the current uboot for the CT working. > Yes F-21 + latest u-boot should work. Basically, this means no fancy networking stuff on the truck with old remixes. :) I can work with that. I only have the one CT, and it is destined as a replacement server. Thanks for all your work. Next to sort out the vlanning problem... _______________________________________________ arm mailing list arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

Hi Robert, As I've mentioned before this is not the location to get support on RedSleeve6. You need to go and speak to them about that. Using a Fedora kernel doesn't make it Fedora. Peter On Tue, Oct 14, 2014 at 8:05 PM, Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: > Just an update on this. I am building a mailserver on Cubietruck. > > I am using RedSleeve6, using the F19 uboot and device and module files: > > http://cdn.opensxce.org/redsleeve/el6/cubieboard2/README > > About the only thing not working as I wish is the ethernet that gets a new > MACaddr at each boot. Right now I am at eth3, as each boot, another entry > is made to: > > /etc/udev/rules.d/70-persistent-net.rules > > with the new MACaddr and the next ethn name. I see the message at boot that > eth0 cannot be found, but fortunately my > > /etc/sysconfig/network-scripts/ifcfg-eth0 > > Gets applied to the current name and I get the MACaddr I want and thus the > IPv6 suffix of choice (to go with the RA prefix). > > I will be putting this server into production next week; switching even my > dozen users over to a new server (and POP/IMAP software!) will be a bit > challenging. > > Then, perhaps, I can get back to F21 testing. And save the Samba server > conversion for later. > > > On 09/09/2014 08:56 PM, Robert Moskowitz wrote: >> >> On 09/09/2014 07:12 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 09/09/2014 10:44 PM, Robert Moskowitz wrote: >>>> OK. back doing some testing. So far all with F19. >>>> >>>> On 09/09/2014 07:02 AM, Hans de Goede wrote: >>>>> Hi, >>>>> >>>>> On 09/09/2014 12:28 PM, Robert Moskowitz wrote: >>>>>> On 09/09/2014 02:41 AM, Hans de Goede wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 09/09/2014 07:40 AM, Marcin Juszkiewicz wrote: >>>>>>>> W dniu 09.09.2014 o 04:51, Robert Moskowitz pisze: >>>>>>>>> Read Hans de Goede's post on the F19 and the Allwinner (Cubie) back >>>>>>>>> on >>>>>>>>> 12/26/2013. He supposedly uses the SID for a consistant local >>>>>>>>> scope >>>>>>>>> MACaddr. I Do get that on my Cubieboard2, but not on my >>>>>>>>> Cubietruck. >>>>>>>> Hans also told that there was a bunch of Cubie* with pre-production >>>>>>>> cpus >>>>>>>> which lacked serial number. >>>>>>> AFAIK only cubieboard2 and olinuxino-a20-micro suffer from this, the >>>>>>> cubietruck is fine. On machines with an all 0 sid this indeed does >>>>>>> not >>>>>>> work. >>>>>> My SIX Cubieboard2 all are fine with a consistant MAC address. >>>>> Good, then later runs of the cubieboard2 have gotten a proper SID, that >>>>> is good. >>>>> >>>>>> My one Cubietruck keeps coming up with the unique MACaddr. Exact >>>>>> opposite of what you are reporting. >>>>> Which version of Fedora are you running on your Cubietruck ? >>>>> >>>>> With the respin images the kernel takes care of getting the MAC from >>>>> the SID, >>>>> with the official F-21 images, u-boot needs to do this, and the u-boot >>>>> included >>>>> is (not yet) new enough. >>>>> >>>>>> Perhaps there is a rev difference in the shipped nand? In all cases, >>>>>> I never did anything with the nand image, but went right to the SDcard >>>>>> image. I just don't get how to do the nand poking to get something working >>>>>> from it. >>>>> The SID is in the SoC, it has nothing to do with the nand. >>>>> >>>>>> Is there any test I can run on my CT? >>>>> You can dump the sid by hooking up a serial console, and then pressing >>>>> a >>>>> key to interrupt u-boot, then do: >>>>> >>>>> md 1c23800 4 >>>>> >>>>> To get the SID contents, see here for example SID-s : >>>>> >>>>> http://linux-sunxi.org/SID_Register_Guide >>>>> >>>>> If this is non-0 on your cubietruck, then you should get a consistent >>>>> MAC >>>>> with the respin images, >>>> Well, I am not. For the Cubietruck. Here is the SID fromthe CT and >>>> different MACaddr from a series of boots from the F19 image: >>>> >>>> md 1c23800 4 >>>> >>>> 01c23800: 165166c1 80485172 49514848 0881e2d7 .fQ.rQH.HHQI.... >>>> >>>> ea:99:af:e5:2f:5b >>>> >>>> ea:22:02:c6:83:c8 >>>> >>>> fe:1d:9a:25:3b:48 >>>> >>>> Then I switch over to a Cubieboard2, also with F19: >>>> >>>> md 1c23800 4 >>>> 01c23800: 165166c4 80485072 56484848 0382c153 .fQ.rPH.HHHVS... >>>> >>>> 02:c4:03:82:c1:53 >>>> >>>> >>>> I notice with the C2, the MAC is the last word of the SID. But for the >>>> CT, I cannot figure it out at all. >>> Ah right, I remember now the kernel code to use the SID for the MAC in >>> F-19 is >>> part of the emac driver, and the A20 uses the gmac driver, that is why it >>> is >>> not working on the cubietruck with F-19. >> >> I thought both are A20 boards. Though the C2 has the 100Mb ethernet, and >> the CT the 1Gb. >> >>>> I have a bit of other testing to do (VLAN setup), then I will switch to >>>> F21 and see if I can get the current uboot for the CT working. >>> Yes F-21 + latest u-boot should work. >> >> Basically, this means no fancy networking stuff on the truck with old >> remixes. :) >> >> I can work with that. I only have the one CT, and it is destined as a >> replacement server. >> >> Thanks for all your work. Next to sort out the vlanning problem... >> >> >> _______________________________________________ >> arm mailing list >> arm(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/arm > > _______________________________________________ > arm mailing list > arm(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Oct 2014 18:23:06 -0400 Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: > This is NOT a question about Redsleeve. Rather about the F19 uboot > that I use with RSEL. It would impact any F19 Cubietruck system, and > as Hans has pointed out any F20 Cubietruck system. Note that Fedora 19's u-boot has zero support for the Cubietruck. so that is not what you are using, only Fedora 21's and newer u-boot have support for the cubietruck. I am not sure what bits you are actually using but it does not sound like fedora is in any of it. if you have the issues with f21 or newer then we can work on them and figure out what is happening.

Dennis _______________________________________________ arm mailing list arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

>>> This is NOT a question about Redsleeve. Rather about the F19 uboot >>> that I use with RSEL. It would impact any F19 Cubietruck system, and >>> as Hans has pointed out any F20 Cubietruck system. We didn't support any AllWinner devices in the F-19 u-boot.

I have no idea what RSEL is, it's certainly nothing to do with Fedora or a Red Hat product, as the acronym might indicate, if it's an "Enterprise Linux" as the acronym leads me to believe I suggest you go to which ever company is providing support for it. This is a Fedora list and as I've mentioned a number of times before not a place for any queries about Redsleeve whether you're using any random component of Fedora, whether it be a mainline component or remix. >> Note that Fedora 19's u-boot has zero support for the Cubietruck. so >> that is not what you are using, only Fedora 21's and newer u-boot have >> support for the cubietruck. I am not sure what bits you are actually >> using but it does not sound like fedora is in any of it. if you have >> the issues with f21 or newer then we can work on them and figure out >> what is happening. > > Check Hans de Goede's post on this list on 7/18/13 > > "Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 > support" > > There are specific instructions for the Cubie at > > http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... > > Just specify cubietruck rather than cubieboard2. Yes, this is a _REMIX_ which isn't supported as part of Fedora. Neither the uboot or the kernel from the remix are supportable by the ARM project. We barely have the resources to support the stuff we ship upstream in the main Fedora. > I believe he stopped with RC3, which is what I and others are using. The > F20 was done by someone else, but I think Hans said the same uboot. > > One thing going for F19 and F20, is that there is video support, so for > those few systems where I need the video interface, I am using it. When I > use the F19 device modules with RSEL, I do get video support, but since > these are servers, I don't use it. This uses an ancient 3.4 kernel with custom patches. We don't have the time, resources or desire to support a kernel from the age of the dinosaurs in terms of the speed of ARM kernel development. > Also for Centos7-arm, Karanbir, back on 7/2/14, was instructing how to start > with a F19 armv7 repo as the starting point for building C7arm. But there > has been no traffic on that list really since early August. So it's a question for CentOS. This is Fedora :-) I'm well aware of what Karanbir is using for CentOS bring up but it doesn't mean that the Fedora mailing list is a suitable location to discuss CentOS related things because it has a tenable, at best, link back to the Fedora ARM project. > I look forward to finishing these conversion projects so I can get back to > testing F21. So once you're back to testing Fedora feel free to come back here with Fedora ARM mainline based questions. Peter

On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: > I do not have this behaviour on the Cubieboard2, just on my Cubietruck. > > I thought it was a problem with the F21 build, but today I am working > with F19 remix: > > http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... > > And I keep getting a different MACaddr. This makes it really hard to > use persistant.rules to control things based on MACaddr. > > Is this just my particular Cubietruck? I remember Hans talking about > since there is no eeprom, he has to use SID as the basis for the > MACaddr. > > Is there anyway for me to set the MACaddr. It is eating up all my dhcp > > addresses. There are rules for what constitutes a valid mac address, if yours in invalid the kernel driver will assign you a random one, and then it looks like a new machine every time. You can force the mac address in userland /etc/rc.d/rc.local using /sbin/nameif + /etc/mactab, it's dirty but it will get you out of the hole if it runs before the dhclient action poisons your dhcp server. If the network driver uses phylib, there is a generic Device Tree name you can use like this inside the ethernet stanza to force it local-mac-address = [ aa bb cc dd ee ff ]; if so, you can think about adding / overriding that DT node in U-Boot before passing to kernel. I sent patches on lkml to improve this a couple of years ago (for Panda, which has no nonvolatile config onboard) by replacing an invalid MAC with computing a consistent per-board MAC from CPU serial ID but The Powers That Be felt it should be fixed by the distros... which as you see...

Hi Hans, >> On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: >>> I do not have this behaviour on the Cubieboard2, just on my Cubietruck. >>> >>> I thought it was a problem with the F21 build, but today I am working >>> with F19 remix: >>> >>> http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... >>> >>> And I keep getting a different MACaddr. This makes it really hard to >>> use persistant.rules to control things based on MACaddr. >>> >>> Is this just my particular Cubietruck? I remember Hans talking about >>> since there is no eeprom, he has to use SID as the basis for the >>> MACaddr. >>> >>> Is there anyway for me to set the MACaddr. It is eating up all my dhcp >>> >>> addresses. >> >> There are rules for what constitutes a valid mac address, if yours in invalid the kernel driver will assign you a random one, and then it looks like a new machine every time. >> >> You can force the mac address in userland /etc/rc.d/rc.local using /sbin/nameif + /etc/mactab, it's dirty but it will get you out of the hole if it runs before the dhclient action poisons your dhcp server. >> >> If the network driver uses phylib, there is a generic Device Tree name you can use like this inside the ethernet stanza to force it >> >> local-mac-address = [ aa bb cc dd ee ff ]; >> >> if so, you can think about adding / overriding that DT node in U-Boot before passing to kernel. >> >> I sent patches on lkml to improve this a couple of years ago (for Panda, which has no nonvolatile config onboard) by replacing an invalid MAC with computing a consistent per-board MAC from CPU serial ID but The Powers That Be felt it should be fixed by the distros... which as you see... > > This has been solved in u-boot in the mean time, u-boot now a days calculates a unique mac > derived from the CPU serial id, and passes this to the kernel. Is this just on sunxi based devices or on all devices that have ethernet without MAC addresses?

Hi, On 09/09/2014 12:40 AM, Robert Moskowitz wrote: > I do not have this behaviour on the Cubieboard2, just on my Cubietruck. > > I thought it was a problem with the F21 build, but today I am working with F19 remix: > > http://docs.cubieboard.org/tutorials/cb2/installation/cb2_fedora_19_card_... > > And I keep getting a different MACaddr. This makes it really hard to use persistant.rules to control things based on MACaddr. > > Is this just my particular Cubietruck? I remember Hans talking about since there is no eeprom, he has to use SID as the basis for the MACaddr. > > Is there anyway for me to set the MACaddr. It is eating up all my dhcp addresses. Then you likely need a newer u-boot, the latest u-boot for sunxi has code to calculate a mac address from the unique bits of the SID, and then passes this to the kernel through DT which then picks this up. The latest upstream u-boot has this.