BPI-R2 - looking for first .config not to start from the very first and waste time


I'm new to this forum and do my first steps in OpenWRT configuration.
Having some basic or advanced linux knowledge - depends on your
definition - and working with linux for the last two decades :wink:
Have reading the first step intro as well as the compile instructions.
Was able to generate and load the first image to the SD card and boot
up the PBI-R2.
Now looking for a .config file to get a fast impression which config switches
and which packages are necessary and useful.

My basic goal is to have a separation between my DSL router (FB7560) and
my home lan. Later on I would like to have a DNSSEC relay and a private
inbox/out storage box ( in common slang called private cloud) for data
exchange. And as a final stage a home observation system via webcam and
a alarm guard with mail/voip notification.

Could you please give me some hints for a proper configuration and what is
the efficient way to achieve this goal - cross compile b4 or just install the default
image and compile on the ARM every needed package - I know this will last a while.

As this will be a longer way as I believe I have two R2 in order improve one of
the SBC while the second is already doing his job with a reduced functionality
at the beginning while I doing my first steps.

Many thanks in advance for useful hints and explanations.


(See post below for why this is not correct)

Based on https://openwrt.org/toh/lemaker/bananapi

http://downloads.openwrt.org/releases/18.06.1/targets/sunxi/cortexa7/config.seed perhaps?

No. BPI-R2 is a completely different animal: https://openwrt.org/toh/hwdata/sinovoip/sinovoip_banana_pi_r2

Hi Guys,

no other help full hints?

What's about cross or onboard compiling?
What's about the minor amount of necessary packages?


PS.: How to mod the Makefile's that just only one target
will be compiled and not all - what's the main target and
the subtarget (mediatek / mt7623 ??) and where to enter
this? (on cli as env var or inside a config file ??)

According to make help the mentioned question above is
obsolate - right?

make help ...

  1. Run "make menuconfig" to select your preferred configuration for the
    toolchain, target system & firmware packages.

  2. Run "make" to build your firmware. This will download all sources, build
    the cross-compile toolchain and then cross-compile the Linux kernel & all
    chosen applications for your target system.

But how rerun the compiler without compiling from the beginning but only the
changed files. Normally make should do this automatically - but the make scripts
seems to initiate always a compilation from the beginning.

make menuconfug

Under sub target select the specific target only


but after make menuconfig, every make call on cli starts again the full compilation!

make[1] world
make[2] target/compile
make[3] -C target/linux compile
make[2] diffconfig
make[2] package/cleanup
make[2] package/compile
make[3] -C package/libs/libjson-c host-compile
make[3] -C package/libs/libubox host-compile

even if I had compiled few minutes b4 and nothing had change.

Why ???


Sorry I would like to upload my make V=sc output to explain what I ment, but only
pic ext are allowed to be uploaded, no bzip/zip/gz/xz files.

Probably just the first run

Just because make runs through the list of targets it needs to build. It doesn't necessarily mean it will rebuild. If the target is current it will just move on to the next.

Dear mbo2o,

perhaps I'm not enough patient,
but see below - every time I run make
I could drink coffee.
How to avoid this?

Machine where I compile 12CPU's@3GHz/32GB Mem

time make
 make[2] target/compile
 make[3] -C target/linux compile
 make[2] diffconfig
 make[2] package/cleanup
 make[2] package/compile
 make[3] -C package/libs/libjson-c host-compile
 make[3] -C package/libs/libubox host-compile
 make[3] -C package/system/opkg host-compile
 make[3] -C package/libs/toolchain compile
 make[3] -C package/libs/libnl-tiny compile
 make[3] -C package/libs/libjson-c compile
 make[3] -C package/utils/lua compile
 make[3] -C package/libs/libubox compile
 make[3] -C package/system/ubus compile
 make[3] -C package/system/uci compile
 make[3] -C package/network/config/netifd compile
 make[3] -C package/firmware/linux-firmware compile
 make[3] -C package/firmware/prism54-firmware compile
 make[3] -C package/kernel/linux compile
 make[3] -C package/system/ubox compile
 make[3] -C package/libs/ncurses host-compile
 make[3] -C package/libs/zlib compile
 make[3] -C package/libs/ncurses compile
 make[3] -C package/utils/util-linux compile
 make[3] -C package/libs/lzo compile
 make[3] -C package/utils/mtd-utils compile
 make[3] -C package/system/fstools compile
 make[3] -C package/system/fwtool host-compile
 make[3] -C package/system/fwtool compile
 make[3] -C package/system/procd compile
 make[3] -C package/system/usign host-compile
 make[3] -C package/system/ucert host-compile
 make[3] -C package/utils/jsonfilter compile
 make[3] -C package/system/openwrt-keyring compile
 make[3] -C package/system/usign compile
 make[3] -C package/base-files compile
 make[3] -C package/firmware/wireless-regdb compile
 make[3] -C package/kernel/gpio-button-hotplug compile
 make[3] -C package/firmware/b43legacy-firmware compile
 make[3] -C package/libs/openssl compile
 make[3] -C package/libs/gettext compile
 make[3] -C package/libs/libiconv compile
 make[3] -C package/libs/libtool compile
 make[3] -C package/libs/wolfssl compile
 make[3] -C package/network/services/hostapd compile
 make[3] -C package/network/utils/iw compile
 make[3] -C package/kernel/mac80211 compile
 make[3] -C package/kernel/mt76 compile
 make[3] -C package/libs/mbedtls compile
 make[3] -C package/libs/ustream-ssl compile
 make[3] -C package/libs/uclient compile
 make[3] -C package/network/utils/iptables compile
 make[3] -C package/network/config/firewall compile
 make[3] -C package/network/ipv6/odhcp6c compile
 make[3] -C package/network/services/dnsmasq compile
 make[3] -C package/network/services/dropbear compile
 make[3] -C package/network/services/odhcpd compile
 make[3] -C package/libs/libpcap compile
 make[3] -C package/network/utils/linux-atm compile
 make[3] -C package/network/utils/resolveip compile
 make[3] -C package/network/services/ppp compile
 make[3] -C package/network/utils/iwinfo compile
 make[3] -C package/system/mtd compile
 make[3] -C package/system/opkg compile
 make[3] -C package/utils/busybox compile
 make[2] package/install
 make[2] target/install
 make[3] -C target/linux install
 make[2] package/index
 make[2] checksum

real	2m53.077s
user	2m8.048s
sys	0m53.907s

Is this due to online verification if something has changed?
make[2] diffconfig


The durations for compilation according to LEDE Project build service
are listed below. I listed the most intensive tasks.
A full build last 1 1/2 hour.

But I was thinking that just a make call without any change should be
much shorter then 3 minutes. What I'm doing wrong and how to adapt



Builder mediatek/mt7623 Build #144 
builddir 	/var/lib/buildbot/slaves/tictex-02/mediatek_mt7623
buildername 	mediatek/mt7623
cc_command 	/usr/bin/gcc-4.9
cxx_command 	/usr/bin/g++-4.9
Start	Wed Aug 29 00:26:45 2018
End	Wed Aug 29 01:30:09 2018
Elapsed	1 hrs, 3 mins, 24 secs

Aug 29 00:26 	01793e8752aa... success #144 The SingleBranchScheduler scheduler named 'all' triggered this build Build successful

updatefeeds Updating feeds 			( 38 secs )
installfeeds Installing feeds 			( 23 secs ) 
defconfig Populating .config			( 12 secs )
dltar Building and installing GNU tar 		( 1 mins, 20 secs )
dlrun Populating dl			                ( 29 secs ) 
tools Building and installing tools 		( 10 mins, 59 secs )
toolchain Building and installing toolchain 	( 14 mins, 26 secs )
kmods Building kmods 				( 6 mins, 39 secs )
pkgbuild Building packages 			( 16 mins, 44 secs ) 
pkginstall Installing packages 			( 17 secs ) 
pkgindex Indexing packages 			( 15 secs )
images Building and installing images 	( 7 mins, 17 secs )
targetupload Uploading target files 		( 2 mins, 8 secs )

When using


I get depending of the status of the source files

make: 'world' is up to date.

That was what I'm searching for - immediate feedback that all are up to date.
But I have to check if I will get a successful and complete build for the mt7623
when changing some source - have to test.


I would say that's an understatement.

Once the cross-compile build chain is built, running with ccache, a clean build of OpenWrt takes me about 20 minutes on an i3-7100T, and about 12 minutes on a Ryzen 5 2600X

Have someone proper knowledge concerning the MT7530
in order to enable the missing two NIC's.
With the default BPI-R2 config I get just eth1/2 as physical
interface wan linked logically to MAC of eth1 and lan0-lan3
is linked logically to eth0.
Dose a patch exist to enable eth2/3 in openWRT/LEDE on

My corrent build is:
root@LEDE:/# uname -a
Linux LEDE 4.9.44 #0 SMP PREEMPT Tue Jun 26 11:00:25 2018 armv7l GNU/Linux

I was thinking the build process take always the newest kernel via git - is this an con-
figuration issue? How I get 4.16 or 4.18 onto my SBC?

Any hints are appreciated.

Thanks in advance

Have found that from github commit list:
So OpenWRT v18.06.1 provides kernel 4.9 und 4.14 - right?

Sorry for confusion and asking?


|13 days ago |Jo-Philipp... |OpenWrt v18.06.1: adjust config defaults v18.06.1 |commit | commitdiff | tree | snapshot|
|13 days ago |Jo-Philipp... |rpcd: update to latest git HEAD |commit | commitdiff | tree | snapshot|
|2018-08-15 |Hauke Mehrtens|openssl: update to version 1.0.2p |commit | commitdiff | tree | snapshot|
|2018-08-15 |Hauke Mehrtens|kernel: bump kernel 4.9 to version 4.9.120 |commit | commitdiff | tree | snapshot|
|2018-08-15 |Hauke Mehrtens|kernel: bump kernel 4.14 to version 4.14.63 |commit | commitdiff | tree | snapshot|

Not so much "provides", but "uses" -- Specific architectures (devices) are supported on 4.9 or 4.14 at this time. As far as I know, there is no "choice" in the build environment over which kernel to use for which architecture (though the build system does support a user-supplied kernel tree). The kernel sources are downloaded from "upstream" and then patched, as needed.