[fedora-arm] Each boot on my Cubietruck, and different MACaddr

Tue Oct 14 22:23:06 UTC 2014

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 at 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 at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/arm
>>
>> _______________________________________________
>> arm mailing list
>> arm at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/arm