Exactly for example embedded WiFi chip does not work on stock OpenWRT.
All patches i have applied on my repo (= not in mainline) are not supported by openwrt.
- internal wifi
- hdmi
- poweroff
- phylink (support with 5.4)
- hnat/hwqos (partially supported in my 4.14)
HI @frank-w
I’m sure you know enough to be able to answer my question 
Is there a way I can flash the stock openwrt image to emmc? if yes, how?
I only know the standard emmc-way 
Imho you need real image (not kernel.bin or sysupgrade) and then flash via dd if=image of=/dev/mmcblkx where x is your emmc-devicenumber. Also preloader neess to be written to mmcblkxboot0. Sometimes it is needed to set partition-config via uboot/mmc-utils
I did that with some third party image I found on the net, and I have the device running from emmc.
I want to run stock image from emmc. from your answer, I can only assume that, as for now, this is not possible. is this correct?
I don’t know how far official support is…i guess basic support is included so you can create a image for flashing to emmc,but i don’t know the settings for that…maybe @lexa2 can guide you here
It’s not the first time PR like this had been submitted there. At least one person is trying to get support into upstream for R2 for quite some time now and I believe I’ve seen this person posting here in other threads. While I wish all the best and good luck getting it accepted into upstream my experience tells me that it won’t be an easy and quick ride. Nevertheless proper support seems to be landing piece by piece all over upstream projects (kernel, u-boot, you name it) so things are getting better.
As for the way to get upstream-built OpenWRT into R2 - it might be a bit complicated. You will have to craft SD image yourself using vendor-supplied preloader and u-boot and couple them with owrt-provided kernel and rootfs. I believe that nowdays owrt produces squashfs-based rootfs for R2 which implies that you will have to use block2mtd to simulate mtd device and specify mtd partitions layout on the kernel command line. To get a good hint on how should it look like you may want to check what cmdline gets embedded into the generated owrt kernel. Most probably you will have to modify it somewhat to get it working with eMMC. I’d expect that you will have to turn on in-kernel support for overriding cmdline with the string that was passed from u-boot and then use serial cable to experiment a bit with u-boot console changing cmdline to make it fly.
I see you have provided a detailed information. I would like to look into this and see if I can get something out of your information. Maybe a working openwrt would be helpful for the community.
I this this description explain much how to package openwrt for R2, which I can try it myself with my limited openwrt knowledge.
Thanks.
NP, welcome.
Keep in mind that info above regarding complexity of getting OpenWRT to work with R2 only applies to upstream “vanilla” OpenWRT. There are at least three viable forks available to end-users (including my fork described in this thread) that make installing OpenWRT on R2 an easy task. There’s no real need/urge to use upstream owrt here TBH as: (a) network will be unstable due to one kernel patch that is included in there while it is known to cause net stalls on some boards; (b) squashfs+jffs2 is a bad idea to be used with storage that is large enough to work good with normal fs like ext4; (с) upstream lacks support for sysupgrade so each time you would like to update your installation will be an “install from scratch” experience.
Is luci working on your build? Like Web gui for normal users to deploy openwrt on R2?
Its not “build”, its source sode fork. I see nothing that should stop luci from working if you include it into your build or install it later on from official upstream repos. Give it a try and ping me back, we can fix problems with it together if any.
As a general remark - I tried to keep changes in fork as minimal as possible compared to upstream. For the most part changes are things like configuring/teaching openwrt’s buildroot how to produce ready-to-use ext4-based SD card images for BPi R2, how to build u-boot that is compatible with R2 and so on. 99.9% codebase remain the same as it was/is in upstream.
1 Like
Perfect, we can work on this together… I will see how I can build this from source and then test it, Then we can see how functional we can get and put luci in the img itself.
I always look at how a normal person can utilise my work. so it should be production ready for even a non technical person. I know this needs a lot of work and patience, but that’s how I like it 
Thanks for your response and effort. I will try it tonight.
I have a build OpenWRT image based on @lexa2 fork with Luci and some other packages on top of it.
1 Like
Would you like to upload it somewhere?
Yes I would upload it later today and provide the link.
1 Like
thanks @LeXa2, I couldn’t ask for a better explanation.
I have two more questions:
- how many times per month do you sync your repo with OpenWRT trunk?
- have you considered submitting patches to the OpenWRT project? maybe start with patches that allow proper ext4 image creation for instance, and then go from there?
thanks again for the time you put in writing such a complete answer.
I believe I had been mentioning it in other thread but it won’t hurt repeating here: I don’t follow OpenWRT trunk (a.k.a. master branch) as that will require too much attention from me. It’s a simple question of availability of “free” time to spend on maintenance which I unfortunately don’t have. I try to follow developments that are happening in “stable release” upstream branches but don’t have any hard schedule for this too - it’s happening from time to time when/if I see some real reason for updating R2 I’ve got working in prod. You know, things like security patches applied to LTS kernel in use and so on. Typical cadence is like once per month, maybe once per two months. To be honest that’s more than enough to have your router sufficiently updated as most of packages in use get updates from opkg upstream binary repos so I only have to (re)build when there’s need to update kernel/modules and/or kernel-dependent packages like openwrt.
I’ve had a way more displeasing than acceptable experience trying to contribute to OpenWRT project like ~10 years ago. It was about adding support for yet another D-Link SOHO broadcom-based routed and fixing several bugs here and there. General attitude from the “receiving” side was ranging from ignoring to insulting so I abandoned my attempts and don’t want to visit that road again. It looks like this attitude is still popular in OpenWRT community (check this thread as an example: https://forum.openwrt.org/t/solved-strange-mksquashfs4-issue/38553 ).
Thus I prefer to benefit from the fact that it is open source software and tend to maintain my own forks for devices I use at home or supply as a “production grade” units to my clients and/or friends. When forks I maintain are non-specific enough to be of a possible interest for general public I tend to share changes at places like github - that’s the case for BPi R2.
1 Like
Thanks for your reply. The world has no shortage of stupid people. For my part, I believe that parting ways is a worst option than to expose them as you did on the thread example you posted. The end result is that, your work ends up being available to much less persons and worst, these bad people are still around to scare away other contributors. Anyway, it’s obviously your call. Thanks for sharing your point of view and course of action.
1 Like