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_ins...
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.
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz rgm@htt-consult.com 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_ins...
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...
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 09/08/2014 09:53 PM, Andy Green wrote:
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz rgm@htt-consult.com 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_ins...
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.
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.
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...
Which Hans said he did in F19, but it is not working on my Cubietruck.
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.
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.
Regards,
Hans
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?
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, 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
Those are the official u-boot sources, and those now have everything needed to run F-21. Note do not use this u-boot with the respin images, that does not work (yet).
anyway to set the SID if it is zero?
Not that we know of.
Regards,
Hans
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_ins... 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:
Makes no sense to me. What do I do with this?
Those are the official u-boot sources, and those now have everything needed to run F-21. Note do not use this u-boot with the respin images, that does not work (yet).
I did try yesterday. And it did not work. ;)
anyway to set the SID if it is zero?
Not that we know of.
I will test the CT tonight.
Hi,
On 09/09/2014 01:59 PM, Robert Moskowitz wrote:
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_ins... 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?
Yes, replace Cubieboard2 with Cubietruck, and replace https://github.com/jwrdegoede/u-boot-sunxi.git with git://git.denx.de/u-boot.git
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?
Probably, if the md command works and the output resembles the one from: http://linux-sunxi.org/SID_Register_Guide
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:
Makes no sense to me. What do I do with this?
It gives you the clone url:
git://git.denx.de/u-boot.git
Regards,
Hans
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.
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
Those are the official u-boot sources, and those now have everything needed to run F-21. Note do not use this u-boot with the respin images, that does not work (yet).
anyway to set the SID if it is zero?
Not that we know of.
Regards,
Hans
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 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.
Regards,
Hans
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...
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@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@htt-consult.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@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.
So perhaps I wandered a bit in my missive. More a report on how things kind of work well enough to use. Eventhough the interface name changes with each reboot, as the MACaddr changes, the system is still able to apply the ifcfg-eth0 parameters to the interface. So it works until we have F21 where Hans is doing it better. Which I need to get back into testing; next week.
And I got good help on the RSEL list for RSEL issues. And the Centos list for regular Centos stuff, and EPEL, and... Well we are all on lots of lists.
take care. Last days of Holiday coming up, the back at it.
On 10/14/2014 05:51 PM, Peter Robinson wrote:
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@htt-consult.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@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@htt-consult.com 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
On 10/14/2014 09:29 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 14 Oct 2014 18:23:06 -0400 Robert Moskowitz rgm@htt-consult.com 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.
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_ins...
Just specify cubietruck rather than cubieboard2.
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.
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.
I look forward to finishing these conversion projects so I can get back to testing F21.
Dennis
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBAgAGBQJUPc4FAAoJEH7ltONmPFDRhd8QALlKDtz9j90rZX/ZOjrCEygY 9PmTHUxiuZpoTO90W7lktX690QfGZOrWfbEr4QewXTll5bNT65cJh3R71DWGVnHa OXpB6CjFGYrooqsWbJZ2yA2UpF6DF8DgJcL6cyBprqo+uV1WMHObDtXuPCYOyx3e 8nSC3RiYn/+Vj4rKMusUJeIMXl9bwK+DRHSohDVCjVTxBdstXpCZ7xw3kNfu3XZk AttdhibEya8eNLno/wrWSdyAIx+QX6Co7Bs69o4ZK9EdOUt7EuXAhY5htnzYgZ2R EnsxFIyNruKmIdmtbmgsAZA+GrhgECKX6nZjz0mL3Do15Gc4jbYTqYs4yi+cb3Z4 adrh/I6m7ObITbGuQPrWtwtBXGd9GXU9bWHGd8MM8xo+sIEkGquGDQpmzOGKYOFK EsQ0akwG5UGcvtXcZIjLfo0zjHJjvg13fbRzgkcSu4iQwuPVihaILRL3qCTVJb0M hZtIJHl8LMBwnhoygp8zTtsWX5QWp9ncFogEhafGgnyh+LOof6pLsXCQA0ONX+Pt UJuiYTQa7DfVCYcfAzYRmpVMBv5w+Amo7SRxFnpOGyQWfJHFUSdahOB1Ftbq1f4Q G7NleHFqQQk3/9HPCAZK5KBfD0hFnqn/M8BKSBs7Lzs3gf8wJQrUGp7J7pJrQkZS BrCePJYIxveO8mVhj547 =qSnO -----END PGP SIGNATURE----- _______________________________________________ arm mailing list arm@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_ins...
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 10/15/2014 05:31 AM, Peter Robinson 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.
We didn't support any AllWinner devices in the F-19 u-boot.
I will end this thread with: Fascinating.
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_ins...
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
Just an update. I am getting a Cubietruck ready from production as a mailserver.
Everytime it boots it is getting a different MACaddr and thus the interface name advances one (eth1, eth2, eth3, etc.). my ifcfg-eth0 content IS being applied to this interface, so it is just that once I get things stable where I will not be booting a couple times a day, I can clean up the rules such that it will come up as eth1.
Going to have to run this way for a long time, as I don't think that Centos7-arm will be any better...
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 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.
Regards,
Hans
Hi,
On 09/09/2014 03:53 AM, Andy Green wrote:
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz rgm@htt-consult.com 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_ins...
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.
Regards,
Hans
Hi Hans,
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz rgm@htt-consult.com 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_ins...
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?
Peter
Hi,
On 09/09/2014 11:57 AM, Peter Robinson wrote:
Hi Hans,
On 9 September 2014 06:40:54 GMT+08:00, Robert Moskowitz rgm@htt-consult.com 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_ins...
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?
This is done by soc specific code, I know that there is similar code in u-boot now a days to set the MAC address on some usb attached nics on panda-boards (iirc). But this is not done for all ethernet devices, since not all SOC-s have serial numbers, and even if they do, you need to know which bits of the serial number are random enough (e.g. on sunxi there are 128 bits, but some encode the soc model, so are rather non random).
Regards,
Hans
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_ins...
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.
Regards,
Hans
On 09/09/2014 02:38 AM, Hans de Goede wrote:
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_ins...
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.
How do I use this later uboot with the old F19 image? What files do I copy from a F21 SDcard to the F19 SD card?
Of course, I actually LIKE that the uboot that comes with F19 has working video, whereas F21 with the more uptodate uboot does not. Sometimes I want a boot that I can use a keyboard/mouse on a GUI with.
I am assuming that the uboot in F21 is the most current for Cubietruck. I have the git instructions for building my own Cubieboard2 uboot from your repository for F21. For F19 on the C2, I use what you provide.
-
Andy Green -
Dennis Gilmore -
Hans de Goede -
Marcin Juszkiewicz -
Peter Robinson -
Robert Moskowitz