gounthar

That's a good idea. I'll see what tool is best used in Android to burn the image. I've never used android for it, but since people with P1/M1 certainly have Android it is a great idea.
I've got a video planned where I show a full installation of Armbian Buster Legacy. I can start it in Android. I'll make the video when my NVMe hat arrives. Thanks for the idea. I wouldn't have thought about it. 

p.s. I've got a Mecool KM6 with S905X4 to review Android 10 on it. I don't suppose there will be Armbian for this? Just asking so I don't say anything wrong. 
I like the box, but I can't get used to Android. For watching video it's ok, but for productivity tasks it is bad.

Mine is 000048.

Mine is 000048.

Hey guys!
 
It's the last day to join the M1 giveaway.
 
https://www.stationpc.com/thread-126-1-1.html
 
Good luck to you all.
 
 

The PCF8523 chip is a good one since it can trigger an alarm interrupt ...

https://www.adafruit.com/product/3295 -> The PCF8523 is simple and inexpensive but not a high precision device. It may lose or gain up to 2 seconds a day. 

It seems I may have found the "issue" in my failed trials post-May 2020 on my NanoPi M4 (rk3399)..
I discovered today (finally) that Kodi's internal ffmpeg isn't being configured with "--enable-libudev --enable-v4l2-request" resulting in missing hwaccels and obviously, no functional hardware acceleration. How this worked before in my build of May 2020 is a mystery (maybe ffmpeg from then auto-enabled these options by chance?).
I first tried to use the FFMPEG_EXTRA_FLAGS variable set on the commandline when invoking cmake, but since it is passed to the ffmpeg cmake script unquoted (see the commit adding it here: https://github.com/xbmc/xbmc/commit/cdbc12608b947d4afefc5bba48dc82e1f3514e52#diff-efa915ad129932095ae6f2a6d75e0d261386dd442b44338b4f6c705e25f1658eR241), only the first item ends up in ffmpeg_conf (due to CMake language rules I believe: https://gitlab.kitware.com/cmake/cmake/-/issues/17113#note_294727).
I have now added the arguments manually and confirmed they make it to ffmpeg, and am currently running a linuxtv-rkvdec-work-in-progress from @Kwiboo's linux-rockchip repository, rebased onto a clean v5.10.4.
Failing to notice this is kind of silly of me, and I'm sorry if I wasted anyone's time with my build configuration issues.
 
H264 decoding works great again (with DRMPRIME/DirectToPlane rendering enabled in the Kodi settings).
I do notice that the limited HEVC content that I have, which worked before (kernel 5.8-rc1 and Kodi/ffmpeg from May 2020), now shows a black screen.
 
Additionally, I tried merging in the changes from @Kwiboo's v5.10.1-drm-rockchip branch, and that gives me an option for a 4k resolution, but when playing back a 1080p H264 file, it appears only the top-left corner of the video output, including the black band around the 1920x800 movie, is shown full screen.
Playing back a 4k Big Buck Bunny MP4 file gives me "no signal" on my TV (it seems the actual 4k resolution is one of those @Kwiboo mentioned in the linked IRC conversation.
Is there a better branch to merge in from instead?
Is there any useful information I can provide to help this get fixed?
 
I hope the kernel v4l2 request uapi can move from staging soon (5.11?) so that the ffmpeg changes can be pulled in there.
 
As always: keep up the good work, I, along with many others, really appreciate what you're doing for these chips!

Ultimately we should have a single kernel source for all rockchip64 devices ;p
At this point neither rockchip64 nor rk3399 is really fit for that. They do not support rk3308 as a simple example. It should probably be some more or less stable cut from Rockchip's master.
Until recently I was actually more inclined to move devices from rockchip64 to rk3399 and make it a base for switching to Rockchip's master whether it would be 4.4 or 4.19 (FriendlyElec is already using 4.19 for R4S).
 
On the other hand boards are now divided ~50/50 between those kernels so we can move Station P1 to rockchip64 if it fits there better.
We will worry about switching to some form of Rockchip's master later - most probably not earlier than with first rk3568 boards...
 
As stated above I see no harm in that.

Haha if I knew that you were working on this I could have saved three hours earlier today
 
Nice job. Will feed this into the Station P1 soon.

ANNOUNCEMENT: The media script is now deprecated, in favor of the official Legacy Multimedia Framework. Please refer to this topic:
 

I just posted the announcement for the official Armbian Rockchip Legacy Multimedia Framework. As you can see on the announcement, I say that from now on all multimedia work will be done in Mainline.
 
That means integrating GPU and VPU acceleration into the official Armbian repos. The timeline is for next Armbian release, in February, if possible.
 
As of today, I am planning to include Kodi and MPV. So if anybody wants to help, it will be much appreciated. 

I saw Kwiboo in irc freenode chat #linux-rockchip and he helped me: showed his last changes for main line (I was need only hdmi fixes)
https://freenode.irclog.whitequark.org/linux-rockchip/2020-12-16 - here is log
https://github.com/Kwiboo/linux-rockchip/compare/v5.10.1...v5.10.1-drm-rockchip - here is his patches to mainline rebased on v5.10.1
 

Yes. I grabbed this one: code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } Armbian_20.12_Arm-64_bullseye_current_5.10.1_desktop.img.xz
Added code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } fdtfile=rockhip/rk3399-roc-pc-mezzanine.dtb
and booted right away.
Desktop does not start automatically, needs code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } startx
Resolution is 1920x1080 and cannot be changed to 1920x1200 via GUI.
Renderer is LLVM, so no hardware acceleration OOB. I'll try to install panfrost from source on top. I am stupid. I should have enabled glamor in xorg conf...
Will also try to use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } xrandr to adjust resolution but I have my doubts that it will work....
 
Edit. Yep, xrandr failed as expected:
code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } xrandr: Configure crtc 0 failed
 

i have everything working. i recommend trying really tested images on p1.
 
http://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2781&page=1#pid13344

I've gotten it from Firefly. Didn't need to pay income taxes or shipping. That's a game of chance. Many times I need to pay for income taxes, sometimes not.
For this I wanted to take my chances. I could use a 2nd RK3399 with 4GB ram. Ideal for running mainline while my M4V2 runs legacy.
It does run too hot for having such a case(85c at 2/1.5Ghz). I'll see to improve that. I suspect thermal pads that I'll replace with copper shims. Done that on my M4V2 and the difference is huge.

Or is it the other way around?

I've gotten my Station P1. 
It looks great. I love the metal case. 
There seems to be PCIe GPIO's. Also RTC battery. 

It is sweet. Thank you for informing me about this. 

 

Or is it the other way around?

Or is it the other way around?

Or is it the other way around?

Or is it the other way around?

Lots of board have similar issues. Debt of compactness. Thankfully you can get adapters for cheap.

Armbian is based on open source software which is IMO the only warranty for our bright future and where its worth investing our precious time into. Everything else (Android, closed 3D drivers, Rpi, ... ) is fully dependent on corporations who owns closed libraries, licences, patents and which can and do decide how and when "open source software" will work or stop working.

Most if not all Androids are running private Linux forks interacting with lots of closed libraries for this and that - those libraries are usually locked to one kernel and can't be reused elsewhere. You can't upgrade anything. FOSS - on the other side - has to reverse engineer those libraries which interact with hardware or write them from scratch. Running pure and true open source Linux is a rare luxury. Especially in ARM world. Running it with open 3D drivers and open video accelerating routines is expensive / luxury ... but we are getting there.

Hardware interface, kernel and special hw dependent libraries, the expensive thing is responsible for that. Usually there are two kernels - one where lots of things works, but its old, not supported by community and incomplete modern one supported by community. OS / cheap component / user land usually does not matter.
 
 
Anything you asks from Armbian is too much. Yearly budget for R&D from public side is 0 since your donations only covers running electricity / bandwidth costs, help with infrastructure upgrades. Whatever you get from this project is already a gift. I understand your frustration, but "simple" things you want, are / can be expensive projects which are far out of our reach to finance (we can only abuse our private cash which we already do).  However, our main focus is to secure a base, not high level stuff like you want. You don't want to have yet another rotten system that looks nice from a surface (video playing inside the browser), but everything else sucks and you can't even change that browser without breaking video playing feature. That is how Android / legacy kernel based OSes looks like. When you look behind the curtains. When you start to use them.
 

They are present but GPU is not responsible for playing video. GPU (mali,panfrost,bigtrost, ...) only know how to deal with 3D / for games, for KODI UI. Video acceleration is a method of bypassing standard implementation. Different for each version of hardware / chip (family). The expensive stuff! We don't even pay attention to the status of development since already keping things up2date is a cost we need to cover from private pockets. Once POC - to play video within video player - is done is just a first step. If you want to get that to the browser is yet another complicated problems. And with Chromium is not the same as with Firefox. Ofc you want to have both and also on some exotic? Yes, some standards exits, but dealing with this exceeds Armbian doers for several ten times. And it is "just" for playing bypassed video inside a browser. Workarounds exists but they are usually on the "not acceptable" levels. 

Do some research on this forum. I think there is also some video from Fosdem about this problematic. Problem is not related to this board or this chip only.

Hello guys,
 
Please I want to ask you who already own the Opi 4 a few questions
 
1) Can you please test screen tearing? In desktop Armbian (Which desktop?)
2) What about GPU drivers in Armbian? So youtube and etc, is encoded via CPU? But running well in 720/1080p 60fps?
 
THANKS
 
Because I bought rpi4, and i am dissappointed... I have tried many linux OS´s , different settings, drivers, etc, but in every desktop OS i see screen tearing in 1080p 60Hz. I don´t think I want too much, i only need smooth scroll and smooth desktop experience...