• Before reporting problems with your board running Armbian, check the following:

    • 1. Check power supply, check SD card and check other people experiences   06/23/17

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information   06/24/17

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

Opi lite MAC address
2 2

32 posts in this topic

Recommended Posts

Hello, I liked to have fixed MAC address to my Orange Pi lite.

At the moment, after every boot I have different one.

First of all, is there "real" MAC for this board? If there is, how the see it?

Then what would be correct way to set static MAC, U-boot/Scribt.bin/ifconfig...?

I am running Armbian 5.14 Jessie server.

 

Share this post


Link to post
Share on other sites

Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like :

options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

 

Share this post


Link to post
Share on other sites

Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like :

options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

Since latest prebuilt images are of version 5.14 and firstrun script won't be executed after dist-upgrade, this change doesn't work yet.

Share this post


Link to post
Share on other sites

 

Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like :

options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

There is such file, and it looks:

options 8189fs rtw_initmac=43:29:B1:0C:84:1C 

But, it gives address from 00:E0:4C: -range

Share this post


Link to post
Share on other sites

I'm using Mainline 4.6.2, and this /etc/modprobe.d/8189fs.conf works for me, it keep the same MAC at every reboot.

But I don't know if the same happen in Legacy kernel.

Just checked: this is what happens

/*
 * Description:
 * rtw_check_invalid_mac_address: 
 * This is only used for checking mac address valid or not.
 *
 * Input:
 * adapter: mac_address pointer.
 * check_local_bit: check locally bit or not.
 *
 * Output:
 * _TRUE: The mac address is invalid.
 * _FALSE: The mac address is valid.
 *
 * Auther: Isaac.Li
 */
u8 rtw_check_invalid_mac_address(u8 *mac_addr, u8 check_local_bit)
{
	u8 null_mac_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
	u8 multi_mac_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
	u8 res = _FALSE;

	if (_rtw_memcmp(mac_addr, null_mac_addr, ETH_ALEN)) {
		res = _TRUE;
		goto func_exit;
	}

	if (_rtw_memcmp(mac_addr, multi_mac_addr, ETH_ALEN)) {
		res = _TRUE;
		goto func_exit;
	}

	if (mac_addr[0] & BIT0) {
		res = _TRUE;
		goto func_exit;
	}

	if (check_local_bit == _TRUE) {
		if (mac_addr[0] & BIT1) {
			res = _TRUE;
			goto func_exit;
		}
	}

func_exit:
return res;
}

So in case bits 0 or 1 of first byte of MAC address are set, 8189fs driver won't consider this MAC "valid" and will assign a random one.

And firstrun always sets first byte as 0x43, which is 10000112

 

Edit: Added comments to function code to clarify return value logic.

Share this post


Link to post
Share on other sites

And firstrun always sets first byte as 0x43, which is 10000112

 

So I added just another bug when adding this to firstun :(

 

The MAC prefix 00:e0:4c is registered for RealTek so should we switch to this in firstrun?

Share this post


Link to post
Share on other sites

That's explain everything ...

If I remember when I faced the same issue, I've explicitly copied the current MAC into the 8189fs.conf file, so I "fixed" the issue by placing a 00:e0:4c manually.

 

In mainline, it looks like the same code, because in fact, when I commit it, the sources was merged with Hans changes, but origins are common.

 

I see that the random init is using this code :

               *((u32 *)(&mac[2])) = rtw_random32();
               mac[0] = 0x00;
               mac[1] = 0xe0;
               mac[2] = 0x4c;

So, Yes, the firstrun should place the same RealTek prefix.

Share this post


Link to post
Share on other sites

I'd like to achieve the same as OP, but on a OrangePI PC with mainline kernel and u-boot.

If I set a fix mac address in the /etc/network/interfaces, the board doesn't boot, so I guess there should be another way to do it.

Share this post


Link to post
Share on other sites

 

In mainline, you can add parameter in ethernet@1c30000 (or &emac) section like :

mac-address = [aa e3 14 b9 b5 12];

 

Pardon my noobness, but to which file should I add this? script.bin? boot.cmd? somethingelse?

Share this post


Link to post
Share on other sites

You were asking "for mainline", so device-tree files.

Using 'dtc' compiler, you have to decompile the DTB file into a DTS, add the above property, and recompile it back into a new DTB. (Keep a backup of the old DTB, just in case)

Share this post


Link to post
Share on other sites

I'm testing on Armbian mainline now

OPi Zero Armbian 5.27.170614

 

need to achieve static mac address per boot in the next 12 hours before 200 OPiZ's get silicone sealed into waterproof containers. so looking into this now...

 

also adding notes for others with same issue who might also be less familiar with the inner workings of armbian and/or linux

 

tried adding the file:
/etc/modprobe.d/8189fs.conf
(note that file didn't exist before)

 

and setting its contents to:
options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

 

but that didn't help (new random MAC address on reboot)

 

theres a file /etc/default/brcm40183 with:

MAC_ADDR=43:29:B1:55:01:01
which doesn't correspond to any of the mac addresses its chosen at boot so far as I know

(also this seems to be cubietrick specific?)

 

also similar in /etc/default/ap6212

 

 

found the lines in /etc/init.d/firstrun:

# set MAC for eth0
  255: 			MACADDR=$(printf 'da:42:ea:%02X:%02X:%02X\n' $[RANDOM%256] $[RANDOM%256] $[RANDOM%256])
  256: 			sed -i "s/^\#[^ tab]\+hwaddress ether/\thwaddress ether $MACADDR/" /etc/network/interfaces
  257  			;;

will investigate here..

 

Share this post


Link to post
Share on other sites

also very curious how to re-activate the firstrun script after it's run the first time already 

(especially how to run it unattended, i.e. flag for it to be run for next boot)

Share this post


Link to post
Share on other sites

manually running :

sed -i "s/^\#[^ tab]\+hwaddress ether/\thwaddress ether 00:e0:4c:55:01:01/" /etc/network/interfaces

and rebooted

still a random address (this time `d6:e2:72:eb:b4:e9`)

Share this post


Link to post
Share on other sites

got some hints from the other thread:

 

 

especially on how best to misuse an internet forum / your life

 

so I keep hearing about 'device tree'

 

looking at the linked code:

https://github.com/megous/linux/blob/orange-pi-4.11/drivers/net/ethernet/allwinner/sun8i-emac.c#L1221-L1226

it looks like if of_get_mac_address fails to get a mac address from of_node then it will assign a random one

so i guess that in order to succeed we need to fix Device Tree?

 

i didn't have this issue on the legacy kernel (but need docker, so need mainline kernel)

any primer notes on Device Tree ?

 

 

Share this post


Link to post
Share on other sites
52 minutes ago, Elliot Woods said:

it looks like if of_get_mac_address fails to get a mac address from of_node then it will assign a random one

so i guess that in order to succeed we need to fix Device Tree?

MAC address should be set by u-boot first. In order to find network devices it looks for aliases named ethernetX (where X is a number) pointing to the network devices DT nodes. In the source DT an alias looks like this: https://github.com/megous/linux/blob/orange-pi-4.11/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts#L58

 

Regarding the wireless driver - no idea if it supports a fixed MAC address and what method should be used for it.

Edit: the first OPi Zero uses the XRadio driver, not a Realtek one, and current mainline images don't have this driver at all in the kernel sources due to many issues with it)

 

1 hour ago, Elliot Woods said:

need to achieve static mac address per boot in the next 12 hours before 200 OPiZ's get silicone sealed into waterproof containers. so looking into this now...

If you are using mainline kernel for production and it works good enough for you (even though I would not recommend it, especially for OPi Zero) - okay, fine, but please use apt-mark hold to freeze the kernel, DT and board support packages (or remove /etc/apt/sources.list.d/armbian.list) to minimize the chance of getting a 200 waterproof useless bricks broken by the upgrade.

Share this post


Link to post
Share on other sites

@zador.blood.stained, I've discovered some thing funny ...

In sun8i-h2-plus-orangepi-zero.dts, there is a comment in the alias section :

/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */

But it seems that it is not true any more, neither in sun8i-h3.dtsi or sunxi-h3-h5.dtsi !

So, that is why we lost fix MAC on few boards when we switched from 4.10 to 4.11 ...

 

I will prepare a patch in the following minutes ...

 

Share this post


Link to post
Share on other sites

@martinayotte

 

hah interesting!

so now i just need to wait for the nightly build server to kick in? and then i can have fixed mac address?

 

 

@zador.blood.stained

thanks for the tips! are you suggesting that the kernel might update itself automatically? or that i might do it myself by accident at some point?

 

 

Share this post


Link to post
Share on other sites
Just now, martinayotte said:

You can also decompile DT, edit by adding this alias, and recompile it.

 

any references on how to do that?

sorry to ask if it's an obvious thing.

Share this post


Link to post
Share on other sites

Assuming you have "dtc" installed (and keep a backup of the original /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb :

dtc -I dtb -O dts -o sun8i-h2plus-orangepi-zero.dts-4.11.12 /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb

Edit the DTS with "nano sun8i-h2plus-orangepi-zero.dts-4.11.12" and add 'ethernet0 = "/soc/ethernet@1c30000"; ' in the "aliases" section.

Then, recompile the DTB :

dtc -I dts -O dtb -o /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb sun8i-h2plus-orangepi-zero.dts-4.11.12

 

Elliot Woods likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

2 2

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.