Igor

https://github.com/armbian/build/commit/c73748bc366e39053691668a9284e03949cb5b3b

Currently, OC is enabled but limited with cpufreq-tools ... but at the boot time, it can jump high and die. Let's see. 3399 boards will remain labelled "testing" for a while.

There, Firefox won't crash due to "out of memory" That has nothing to do with memory. If you want to play youtube videos on your 512MB Orange Pi one, use search. It is possible. Providing video accelerating videos within the Chromium is a complicated and expensive problem. That's why this is n/a.

No. Not on any ARM board. Android only. But you can play youtube outside browser. And yes, you don't have enough memory.

The most generic will (probably) be the rk3399 branch. Currently, it is under RFC.

Working on it. I need help here https://github.com/armbian/build/blob/master/config/sources/rk3399.conf#L95-L106 -> a working boot configuration for Rockpro64. I haven't got to boot the board properly yet.

I can only confirm that A64 boards are mostly broken ATM. By joining and slowly discovering where is the problem and fixing it? https://docs.armbian.com/Process_Contribute/ https://groups.google.com/forum/#!forum/linux-sunxi You can try to build an image on your own by using DEV targets, kernel 4.18.y. IIRC it boots, but many things do not work yet. Check kernel development progress here: https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

That is not a problem. How about this way: RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle RK3399 (RockPRO) and RK3328 (Rock64) -> rockchip64 (ayufan source) RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future

That should be possible, yes. We use the same kernel source, but one kernel is packed into rk3328 and another into rk3399. The plan is also to merge Rk3288 in ... but we already had many troubles.

It is a total mess which means a lot of work. I was trying a few hours now to come up with some working combination, but problems are just piling up: random gmac, hanging on boot, ... I used radical solutions as such: ... and using stock .dtsi for the rest. Additional families? Or someone else takes a look if he can come up with something. rk3399-pine64 rk3399-fa joined once into rk3399?

root@nanopct4:~# lspci 00:00.0 PCI bridge: Rockchip Inc. RK3399 PCI Express Root Port Device 0100 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 root@nanopct4:~# cat /proc/partitions major minor #blocks name 1 0 4096 ram0 259 0 500107608 nvme0n1 259 1 1024 nvme0n1p1 259 2 500104192 nvme0n1p2 179 0 7761920 mmcblk0 179 1 7590288 mmcblk0p1 179 32 15267840 mmcblk1 179 128 4096 mmcblk1rpmb 179 96 4096 mmcblk1boot1 179 64 4096 mmcblk1boot0 252 0 51200 zram0 252 1 262144 zram1 252 2 262144 zram2 252 3 262144 zram3 252 4 262144 zram4 Huh. Nothing suspicious here. http://ix.io/1ldb

https://github.com/armbian/documentation/blob/master/docs/Release_Changelog.md (please add what you think I forgot and is relevant to mention, up to 6 months back) all images were rebuilt, except boards which support ended, and with a few exceptions which are still in the works (Tinkerboard, MiQi and perhaps we can move T4/RockPRO to the stable) and will be added probably next week. I already test a few and so far I couldn't find troubles. I record them here: https://github.com/armbian/testings. The result is displayed in this https://beta.armbian.com/buildlogs/report.html table and when it is filled up, an update to the main repository on all images can be rolled out.

yes

As I predicted, you are using Jessie which Network manager has many problems ... problem is not related directly to Odroid XU4 nor Armbian so I am moving this to Common section. Disable Network Manager and use ifupdown only, while the best solution is to start with a Debian Stretch.

Nope, the one I need is missing , use: armbianmonitor -u

That is just yet another marketing BS which usually originating from upstream, from Allwinne's claim that they will produce the chip this or that long. In reality - it means nothing since all other chips will be produced at least that long.

Perhaps we could use this for our NEXT/4.14.y branch? It shouldn't be worse.

Main project goals haven't changed: making good Linux for SBC, make them usable. I am not doing any major short-term plans until major maintenance work and infrastructure changes are (almost) finished. I am drowning in those tasks and image for R40 is a side product of doing that. It was like - ler's play a little in between and since basic things works, I made an image. It is not present at the download page as you expressed that you don't want to see them there. I'll write sum up what has been done when possible.

And which was the original firmware? Was it kernel 3.10.y?

Debian Jessie version?

Should be fixed with this: https://github.com/armbian/build/commit/0c66fed14b494bc8b56fe4582509698635d09e26

Perhaps your system is broken? What have you done to? It doesn't even run armbianmonitor

The main client is a notebook with Intel AC 7265 wlp58s0 IEEE 802.11 ESSID:"ARMBIAN" Mode:Managed Frequency:5.2 GHz Access Point: 40:A5:EF:D7:FC:DF Bit Rate=866.7 Mb/s Tx-Power=22 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=56/70 Signal level=-54 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:20 Missed beacon:0 5m from AP Running speed test app on my phone (AC wireless) simultaneously.

Do you use the same SD card? And try Armbian Stretch version, that you will compare Debian vs. Debian https://www.armbian.com/orange-pi-one/