hi, it does not contain any code for r64…
it would be nice to start repo with upstream u-boot and add your Patches on top (not one commit including upstream-source mixed with your changes), so everybody can see what is changed…
as an example i’ve added content of this folder to a branch in my repo:
https://github.com/frank-w/u-boot/commits/2019-07-bpi
but good that are no objects and generated files in the folder uploaded 
Using Micro USB for power with 2.1Amp this works on 4.4 kernel. But not on mainline.
@sinovoip Many thanks!
Why don’t you push it as fork of mainline uboot?
Sure will do, but not today - in a middle of house move right now. Probably would be able to test it on Friday.
please try it with DC power.
Thank you for the advice, But the DC Connector is not a standard one and I cannot find it anywhere locally.
I will have to look for some device which uses something like this.
@sinovoip i made a connector to the board and tried it with dc and it is still the same.
I tried a fresh image of debian 10 lite.
Please advice
good to have one uboot-repo without being mixed with kernel and for all devices without generated files (like in the kernel-repos).
with this repo you still have the possibility to include it in your kernel-repo for combined building (git submodule or get source via building-script). But some users only want to build one of them so they don’t need the other one.
as i’ve wrote in other thread it will be better to start with upstream code and commit your changes on top of the original uboot-code to see what you have changed. not 1 commit containing both squashed together (which cannot be shown by github webservice because of its size)
will r64 added in next time (before upstream support it)? will it be updated to more recent versions?
for BPI-R64, we still cowork with MTK ,if ready ,will update.
Update our latest status for developing mt7622 upstream uboot
We have some major differences with Ray’s version
Status:
It seems that some works are overlapping (with Ray’s works), maybe we can integrate the patches of both sides, but we think mt7622 upstrem u-boot should be 64 bits.
Can we see your current work to compare / migrate to 64bit too?
Thanks for reaching out.
root@bpi-iot-ros-ai:~# cat /proc/cmdline
board=bpi-m4 console=earlycon=uart8250,mmio32,0x98007800 console=tty1 fbcon=map:0 console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait fsck.mode=force fsck.repair=yes service=linux sdmmc_on=0 loglevel=8 initcall_debug=0
root@bpi-iot-ros-ai:~# cat /proc/sys/kernel/printk
1 4 1 3
All checks out as it seems. Could the level be set wrongly on the RTW module itself? Can a module (8821cu) itself be silenced by doing some modprobe options?
Try removing
loglevel=8
From bootargs (maybe another var used in bootargs) in uEnv.txt
I don’t know that driver…maybe it is compiled with DEBUG option
frank-w in kernel build bpi-r2_5.4.0-rc5-merged wat features are supported ?
In merged-tree all feature-branches except second gmac (wifi,poweroff,hdmi) are merged, and of course all mainline-options from older lts.
try using root / 1234
Any update on this?
Will be waiting to test the mainline built.
Confirm this issue (i.e. unable to install debian buster due kernel crash occured). Issue located at linux-dtb-next-sunix64 package. Temporary solution:
When logged in as root, is there any way to tell which hardware version of the Banana Pi you are logged into? Some sort of hardware signature, or some combined metric??
which are you mean???, github???
BPI-M3 new image:Banana PI BPI-M3 boot ubuntu 19.10 & debian 10 with grub
image:
Banana PI BPI-M3 ubuntu 19.10 mate-desktop:
Banana PI BPI-M3 debian 10 lite