lanefu

Hi! reminding everyone of meeting
 
 

many thanks for your time. it did not resolve the problem but it switched to modsetting
 
Graphics:
  Device-1: display-subsystem driver: rockchip_drm v: N/A bus ID: N/A 
  Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A bus ID: N/A 
  Device-3: rk3399-mali driver: panfrost v: kernel bus ID: N/A 
  Display: x11 server: X.Org 1.20.9 driver: modesetting 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mali T860 (Panfrost) 
  v: 3.1 Mesa 21.1.0-devel (git-befd9fb 2021-03-21 focal-oibaf-ppa) 
 
 
what component of those it's the faulty or the one without this kind of support if you can guess?
the thing is we run wine games... and they are very low res. 640x480 and 800x600 are quite common then and it doesnt work at all at those resolutions. 
 
 
@Kwiboo do you know something about this?

 
 

PS send me one 

yeah I'm excited about 8Gig chips...  skeptical on AI functionality until there's a way to build DKMS against mainline..

After fiddeling aroud I finally have the helios64 also running solid. I never had any freezes before just some problems with getting the system to boot from the emmc device and, see other thread, with setting up OMV - LUKS - Snapraid - UnionFS
 
I am currently under: Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux
OMV Version 5.6.2-1 (Usul)
 
So I would say that OMV is not the culprit out of the box. The system works fine but it always depends on what kind of plugins you are using etc. So far I have no docker installed here but I certainly will do that again. I do recommend the OMV Backup Plugin so I can boot from the latest stable release via SDcard if I mess up with something. That's also nice.

We will provide soon instruction on how to update SATA controller (JMB585) firmware with the latest version. Let see if it has positive impact or not.
 
For the new revision we will reinforce noise filtering on the SATA controller in case this is part of the root cause in some cases.

@Wofferl those are the exact same model as three of my disks (but mine aren't "Plus"). I've used these disks in another machine with ZFS and zero issues (ASM1062 SATA controller). So if we assume the problem is between SATA controller and disk, and while I agree with you that it's probably in part a disk issue, I'm convinced it's something that would be fixable on the SATA controller firmware. Perhaps these disks do something funny that the SATA controller doesn't expect? And based on all my testing so far, the SATA cable also plays a role, meaning perhaps there's a noise-factor in play (as well).
 
Side-note; Western Digital really screwed us over with this whole SMR fiasco, didn't they. I'd be pretty much ready to throw these disks in the trash if it wasn't for the fact that they worked perfectly on another SATA controller.
 
@grek glad it helped! By the way, I would still recommend changing the io scheduler to none because bfq is CPU intensive, and ZFS does it's own scheduling. Probably wont fix issues but might reduce some CPU overhead.

I tried a lot few days to driver a 3.5" TFT(the display ic is ST7701S,touch ic is FT5316) MIPI DSI color display panel on Orange Pi 4 with kernel 5.10.y .
but I unexpected found it worked on linux 4.4 legacy kernel ( but I don't want use legacy kernel ),that below:

 
But on kernel 5.x have some serious error in dmesg:
[ 6.135383] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) [ 6.136150] rockchip-drm display-subsystem: bound ff960000.mipi (ops dw_mipi_dsi_rockchip_ops [rockchipdrm]) [ 6.405472] dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO [ 6.427829] dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO [ 6.448508] dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO [ 6.469160] dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO [ 6.490170] dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO ......  
what's mean 'dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO' ? I found the code in https://elixir.bootlin.com/linux/v5.10.6/source/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c :
 
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val) { int ret; u32 val, mask; ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS, val, !(val & GEN_CMD_FULL), 1000, CMD_PKT_STATUS_TIMEOUT_US); if (ret) { dev_err(dsi->dev, "failed to get available command FIFO\n"); return ret; } dsi_write(dsi, DSI_GEN_HDR, hdr_val); mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY; ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS, val, (val & mask) == mask, 1000, CMD_PKT_STATUS_TIMEOUT_US); if (ret) { dev_err(dsi->dev, "failed to write command FIFO\n"); return ret; } return 0; }  
Someone has tried to do this ? 

Quite a while ago developers decided to rename the dev branch to edge to reflect its purpose better: https://armbian.atlassian.net/browse/AR-233
 
This now finally happened. Our documentation has been adjusted as well. For details feel free to check these commits:
 
https://github.com/armbian/documentation/commit/6c9985c9f5a0f593ab2593eb8054b6c658445d25
https://github.com/armbian/build/commit/0cdffb29b07305209efb12cf3b5ac6032d3a1153
 
For those who do automated and/or scripted building take note to adjust it accordingly.
 

Another things I've been playing with in my spare time. Better identification of the SoC that some of these boards use. For example my NanoPi M4V2 (RK3399) kicks back this:
 
tparys@hobbes:~$ ./arm-chip-id.sh 4x Arm Cortex-A53 @ 1416 MHz 2x Arm Cortex-A72 @ 1800 MHz  
Not sure if it's useful, but might be more descriptive for end users who don't know much about their systems, or for describing controls for each CPU cluster in their SoC (see this post). Apologies in advance the bash is a little hard to read as it's digging through sysfs topology bits.
 
It also breaks if the first CPU in a cluster is knocked offline. Not like anyone would do that, right?
arm-chip-id.sh arm-chip-id.db

Great! Looks promising and IMO it's probably a way to go unless there are (much) better ways?
 
Now we need someone with some spare time and some experience in managing (such) projects  
 

We also need to have a complete design, plan of actions and some definition of done per sections. Some draft was initiated https://armbian.atlassian.net/browse/AR-638 
 
 
but someone has to step up and keep an eye on the overall project execution structure and speak up when needed. I have time to help here and there, to cheer up, but can't drive development or do much of coding since I already drive too many things. My performance would be terrible and most of current contributors are also in the same situation. This should be an opportunity for fresh people which have a desire to help on community projects with their know-how and scriptfu.
 
Who can work on this and how much? Finding and calling out people that were complaining or recommending things related to this script, those who were filing an issue might also be good way to start? This is their opportunity to add their 2c directly to the code instead opening an issues that were actually never addressed.

@IgorPlease do not think that your efforts are unappreciated - they are, and greatly so. I was simply concerned that the board status was not what I expected. 
 
I also agree with the work-around - and thus me taking the builds and working out which would work for @robocone
 
I am also not adverse to providing workarounds when I can, and, as time allows, I will attempt to identify exactly where the problem is, and share same.
 
Once more, the efforts here are greatly appreciated (at least by myself) and I remain grateful for all of your efforts. If I can find the cause then I shall do so, but. for me. the 'free' is very valuable
 

Stable System: Absolutely
I'm running with all latest maintenance & OMV5.
Linux 5.10.21-rockchip64, OMV 5.6.2-1(Usul)
 
---- but I'm keeping things very simple...
NO RAID
4 x HDD ALL THE SAME
NO ZFS
BOOT FROM SD 
AUTO SHUTDOWN & RESTART EACH 24 hours 
 
-- until I get to the apps
21 Docker containers running various apps & services.
 
I've had one docker image fail to come up on a couple of occasions.
 
So ... I'm a very happy customer.
My Data resilience doesn't come from RAID (which I really don't like 'cos 8TB disks take forever to rebuild).
I just backup critical data to my old trusty Helios4! 
 

One of the interesting features of extlinux.conf is the ability to present a boot menu.  I have played around with it a bit to have different kernel versions installed and switch between them at boot time.  With a boot menu and hdmi support in u-boot, it brings some nice capabilities.

@lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel
 
@SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working)
 
the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use
 
the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup
 
just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic
 
@lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe
 
good luck and best wishes - hexdump

That's how it done my friend.  nice work!

That's how it done my friend.  nice work!

Obviously the author does not need further assistance. Therefore assuming solved.

Correct.  No DKMS modules needed.  No container needed.
 
 Armbian has shipped with native wireguard support for probably 2 years.   wg and wg-quick are already installed.

Anything based on RK3399 SoC is going to be the best overall desktop experience 

Wow rollin the dice.  Im optimistic on their behalf and won't make any passive comments about the Rock64

Suddenly it makes sense what I read in the recently published March Update: Status Report:
 
 

Sorry about the bad vibes.   Honestly I think we need to do a better job at lowering expectations.     RPI sets a high standard for general user experience because of the limited scope of targeted devices, volume of developers and community, and defaulting first to out-of-tree drivers, blobs, and resources via NDA's with Broadcom to ship a product that has full software functionality to accompany its hardware.

Alternative SBC vendors often create a false-promise of users having a similar experience with their product by the way marketing hardware capabilities and leaning on the reputation of RPI by selling a similar product.
 
End-result is users buy these alternative SBCs, have a terrible experience, hear Armbian is the best, come to Armbian and have better software, but Armbian still focuses on mainline, so the experience isn't that of RPI and articulating the many nuances as to WHY Armbian can't just work like the Raspian experience on RPi because challenging.    Then the fall-out ensues when newer users treat Armbian like a vendor and share their dissatisfaction that a capability for a piece of hardware they bought from someone else isn't work with community software integrated or provided by Armbian.
 
We could certainly use more tenured technical people to help articulate that message.

I am running the latest Armbian 21.02.3 on two NanoPCT4s.
Thanks to everyone for this. I didnt think I would see this performance on this device.
But here it is and I see Armbian is getting good notice for this.
I dont know how they did it but these devices are running very well.
I am a little tired this week so I dont have any technical details.
I want to just ramble (opinionate) on how nice this is and what I like about it.
I am running standard Focal Gnome Desktop from Armbian Download.
I just disable the pwm-fan module and run hot.
As long as I dont make -j6 I can avoid meltdowns.
I run Firefox and Microsoft VSCode. I run a complex desktop and my
standard install involves a day of burnin compilation.
I can run Firefox videos and Microsoft Code.
By the way Code can now be downloaded direct from Microsoft.
I run a lot of Python and JavaScript and C++ [avoid Java and C# at the moment
but really I dont have much time considering I do more and more C/C++]
and use Python as scripting language for C. I compile Sage Math 9.2
and that will halt this machine at make -j6 and no fan.
with fan, no problem. but make -j3 works OK with no fan.
After compiling these little ARM devices run SageManifolds doing complex
Jupyter Lab interactions. Pretty slick.
So I think this is a wonderful desktop.
 
I know the Gnome people own GItHub and Microsoft
TypeScript backended on GitHub integrated with the wonderful
Microsoft Code is a great desktop that Armbian is Smart to invest in.
 
more later.
 

More background on initiative here:

https://armbian.atlassian.net/browse/AR-689