Official OpenWRT 18.06.4 for Banana Pi BPI-R2 image released 2019-7-04

(Maciek Szelągowski) #1

Yesterday OpenWRT 18.06.4 was released.

Downloads for BPi R2:

I will try to upgrade and let you know.

(bpi team) #2

OpenWrt v18.06.4 Changelog

(fengaiyu) #3

How to use the file ***.bin? Can i flash the ***.bin to SD card?

(bpi team) #4

please see here:

(fengaiyu) #5

How to use the file ***.bin?

(Alexey Loukianov) #6

Two my cents: “official” upstream support for BPi-R2 in openwrt is half-baked at the moment and is something not to be used unless you’re an advanced user and really know what you’re doing and why. For example no ready to use SD or eMMC images are produced by upstream. You will have to create the image yourself by hand. Also only squashfs rootfs is provided which is not what you’ll be comfortable using with this board. Memory available in official build is limited to 512Mb instead of 2Gb due to error in the DTB. There are more reasons why I’d suggest you not to use upstream image and stick to one of forks available out there with better support for BPi-R2.

(Frank W.) #7

is there any manual how to create an image from the official bin-file? and how to include a squashfs-rootfs…

(Alexey Loukianov) #8

None that I’m aware of. It is not a rocket science TBH but thing is using upstream “vanilla” OpenWRT on R2 is not a reasonable choice for now.

Re squashfs - it is squashfs which is used as a default rootfs for vanilla image. It has some drawbacks. Squashfs is a read only FS. To be able to install additional packages OpenWRT usually pairs it in overlayfs with jffs2 used as a backing storage. Jffs2 volume is expected to be auto-created on the rootfs_data MTD partition, which is an OpenWRT-specific subpartition that gets auto-created by scanning rootfs MTD partition on fs block alignment boundaries for a 0xDEADCODE marker. So to have overlay+jffs2 functionality available one would have to supply proper block2mtd kernel options on u-boot commandline (or in DTD - whatever works with upstream kernel configuration) and - possibly - would have to make an extra step to mark the end of squashfs filesystem with 0xDEADCODE at a proper alignment boundary. And even after having this done one will be facing disappointing performance level with the setup like this if jffs2 volume is substantial in size. I had tested how things work with 2GB of eMMC space provided for jffs2 backing store and it took several hours just to finish jffs2 first-time initialization process. It is turtle slow compared to the speed of ordinary ext4 fs with the same board. But guess what, there’s no official support in upstream OpenWrt for ext4 rootfs on BPi-R2.

(Maciek Szelągowski) #9

Wow, great answer.

Is that any way to build 18.06.4 image without those “problems”? And how to build additional packages? Can you give us some manual? Or point to it?

Thanks in advance Alexey!

(Frank W.) #10

isn’t it possible to use ext4 as overlayfs?

(Alexey Loukianov) #11

18.06.4 - not so sure. 18.06.x - yep, one will have better luck using one of community-provided OpenWrt forks. Or use something like “OpenMPTCProuter”. Among other variants there’s my fork, check here:

I hadn’t had a chance to update it with latest changes to 18.06 release branch but its state it pretty close to what had been tagged as 18.06.4. And I’d expect that updating source to the latest changes would be as simple as blind merge. I’m planning to take a look onto this later on, maybe this or next weekend.

Build process is exactly the same as for any other OpenWrt image. There are plenty of guides available out there for googling. Best way to start IMHO is OpenWrt’s official wiki.

(Alexey Loukianov) #12

In broad understanding of “possible” - yes, it is technically possible. It is just not what is supported out of the box by OpenWrt. OpenWrt’s approach to filesystems is a hard choice: squashfs+jffs2 in overlayfs or single filesystem rootfs like ext4/jffs2. And it is reasonable as overlayfs approach fits well for devices with small amounts of onboard flash memory (like 4-8MB) while single filesystem rootfs works well for more server-like use cases. It is possible for sure to patch OpenWrt sources to implement overlayfs with squashfs + ext4 but (a) it is “to patch” thus it is not upstream provided and would require personal building of changed sources and (b) there’s no real advantage in using overlayfs with eth4 - it is faster and easier to use only ext4 instead and drop the overlayfs bit. Nevertheless enabling ext4 rootfs for BPi-R2 also requires small amount of patching to OpenWrt sources but it is way easier and had already been done in several forks (including my fork I linked to earlier),