Jump to content

Search the Community

Showing results for 'rock64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Under 20$ the Raspberry Pi Zero W for 10$. It's very slow with only 1 core at 1Ghz. You can watch youtube with kiosk browser. And surf, very slowly. The Banana Pi M2 Zero for 20$. A lot faster. 4x1.2Ghz. You need a good heatsink for it or it overheats constantly. Not very good video playback. For 25$ the Rock64. Faster, better, but no wifi on-board. A raspberry pi 3b+ is 35$ and again a bit better. For your use case an Odroid C2 is perfect. Good Youtube playback, fast, doesn't overheat, ... That's about 50$ Those or the ones I have, and I can recommend. But for 20$ you will not get much. You need to know that many sbc's don't have hardware acceleration for video playback in browsers. So expect choppy and low resolution video with most. The Odroid C2 does this best in Linux. Also if a board only has 512MB ram then you want be able to open many tabs. FriendlyArm also has got some interesting cheap boards. I review sbc's on their desktop capabilities. Of all those I've got a video, except the C2. https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg
  2. I would suggest a Rock3399 board. With a big enough heatsink it can be fanless. Also if you underclock it a bit... There's the Orange Pi RK3399 with sata on-board, USB-3.0 type C, 2GB ram, ... But the Orange Pi has got less software support than many other RK3399's. http://www.orangepi.org/Orange Pi RK3399/ Otherwise I would suggest the NanoPi M4. This does not have SATA, but there's a 4xSATA hat comming for it. And it has USB3. It's got an amazing heatsink. When running it at 1.8Ghz/1.4Ghz then it always stays under 70°C when constantly maxed out without a fan. There's a 2GB and 4GB model. Gigabit ethernet. Great wifi 2.4Ghz/5Ghz + blue tooth. It's the most power efficient of the RK3399 boards. If you want it cheaper and don't need a lot processing power you could go for Rock64. Again no SATA, but USB3, gigabit ethernet, 1/2/4GB models, ... With a big enough heatsink it can run fanless. Biggest disadvantage is it's a slow CPU. One that has got everything you want is the Banana Pi W2. 2 SATA interfaces, USB3, 2GB DDR4, PCIe, 2Xgigabit ethernet, ... It's a very different SBC than others, I don't know about the software support of this one. I think I'll be able to make a review video about this next month. http://www.banana-pi.org/w2.html Here my video about the NanoPi M4 Here my video about the Rock64 If you also would like it to be able to play games well. Then the Odroid XU4-Q could also be a possiblity. When underclocked enough it doesn't need a fan. There are many others. It depends on how much you want to pay, how much processing power you want, ... The Rock64 is good enough to run a simple server. But if you want to be future proof, then I would rather go for a NanoPi M4 or so. Greetings.
  3. Igor

    NanoPi NEO4

    We can/could merge Nanopi M4/T4/Neo4 under one image, which share boot loader and kernel family rk3399. We wanted to add Rock64 and Rock64PRO to one common rockchip64 family. To maintain one kernel source ... but its sadly way too much work and this is postponed to the future. Since we have two legacy kernels for RK3399 and since boot loaders are different, we can't provide one image.
  4. I agree - your build is working. But on the box v88piano constantly crashes, the operating system on micro SD collapses. As a result, the system load stops with the message "kernel panic". It was checked on your (and not only your) builds of LibreElec and linux with different device trees - z28, Rock64, etc. Could you add support for the box v88piano to your builds?
  5. IMHO taking into account the need for GPIO, to date (in the near future this situation may change) for you to optimally use models based on RK3328 (Renegat Rock64 etc). This is optimal in terms of cost and the result obtained for your tasks. And advice, do not chase the cheapness, it is better to spend 100 and use the purchased piece of iron in full compliance with the tasks for many years than to spend 50 and then not get the desired result (at best, somehow use the purchased iron, at worst-throw in the trash). https://forum.armbian.com/forum/21-rockchip-3288-3328/ https://forum.armbian.com/forum/16-amlogic-s905x/
  6. Well, the FreeIPA release just updated on Friday (2018/10/05) it looks like to solve the issue... now I just have to wait for it to make its way into debian/ubuntu/armbian's repos (or get Fedora working on Rock64 but so far that's been a fail - I expect the repos will update before I get Fedora booting on the Rock64)
  7. Thanks for the insights. I hope we can make it work on armbian at some point. I know ayufan (https://github.com/ayufan-rock64/linux-build/releases/tag/0.7.9) bundles it on his builds but not sure how.
  8. A few things do not work yet on 5.60 version (4.18 kernel) 1) reboot does not work -- only function as shutdown. 2) I have not figured how to change the resolution to 1920x1080p60 yet (HDMI) -- it is now only at 1024x768 3) WiFi does not work and the addon USB card TP-Link TL-WN727N is not working out of the box as in 3.14 kernel. I followed the following -- by editing armbianEnv.txt to add "disp.screen0_output_mode=1920x1080p60 " (this method works for my Rock64 board) but it does not seem to work. https://docs.armbian.com/User-Guide_Fine-Tuning/
  9. I assume you need at least an mpc251x driver (as module). Seems not to be here for rock64. Go through this one to see how you can change that.
  10. Hi. I added a second wireless interface to my Rock64 and created a wifi hotspot using armbian-config. Now .local domains are not resolved anymore. I tried changing in files /etc/resolvconf/resolv.conf.d/base and /etc/resolvconf/resolv.conf.d/head IP from 8.8.8.8 to 127.0.0.1 but nothing changed. avahi-resolve-host-name is ok: christian@rock64:~$ avahi-resolve-host-name orangepi2mini.local orangepi2mini.local 192.168.0.12 but christian@rock64:~$ ping orangepi2mini.local ping: orangepi2mini.local: Name or service not known Could anyone point me on what could have gone wrong? Many thanks. Christian
  11. Sure, I won't miss it. The problem is that enabling option CONFIG_USB_HIDDEV is not enough, something is still missing. I wanted to create a specific post in a general section because maybe someone else knows how to do it, but no problem. I'll try to compare the configuration kernel file of the other Ubuntu distribution, which I think is more similar to the Odroid XU4 Armbian configuration file than the Rock64 configuration file. Thanks
  12. Yes, it works. So I can use the kernel configuration of the Rock64 board, I think this one linux-rockchip-next.config But it not simple, too many differences ... :-(
  13. Hi All. I have some confusion on Touchscreen interface. My ques is very basic on LCD interface types ... apologies for that. I like to use a 3.5" Touchscreen. For CPU either Allwinner H6 and RK3328 is in my choice. I have attached the Touchscren Datasheet. Here we will build a custom PCB for the Touchscreen. But I found RK3328 don't have any LCD Interface. So is there any possible way to use this Touchscreen with RK3328 based SBC like Rock64? On the other hand Allwinner H6 have RGB LCD port. But in Touchscreen Datasheet it said LCD Driver IC is ILI9488. As H6 have direct RGB Port so do we need to use this ILI9488 Driver? There are many Touchscreen Shield connects with GPIO Header ... how they are communicating without a dedicated LCD Interface? Thanks in advance. Regards. HT035K1HV50C-U-V0.pdf
  14. Can you help me? How can I do it? On the Rock64 I have the ayufan Stretch image 0.6.44, kernel 4.4.132. I have to search in that kernel configuration. And I can try the Rock64 Armbian image to check if apcuspd works with it. Thanks
  15. Bionic and Stretch share kernel. Try to compare working (rock64) with nonworking configuration ... perhaps some other config option is needed or there is a bug in Odroid USB stack. You can also switch between different kernels for XU4 if that helps ... Wrote on mobile
  16. The version of the image 20180930 with support for full-screen video through MPV with HW. To use MPV with HW, you must run these commands. sudo add-apt-repository ppa:ayufan/rock64-ppa sudo apt-get update sudo apt-get install ffmpeg mpv libmali-rk-utgard-450-r7p0-gbm Rename the file in the home directory of the user ".config/mpv/mpv.conf.rkmpp" to ".config/mpv/mpv.conf" Reboot the system. Please note that full-screen video with HW works only through MPV.
  17. Nope, everything as expected. The M4 number in the list https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md has been made with mainline kernel which shows way higher memory bandwidth on RK3399 (check the other RK3399 devices there). Cpuminer numbers differ due to GCC version (Stretch ships with 6.3, Bionic with 7.3 -- see the first three Rock64 numbers with 1400 MHz in the list -- always Stretch but two times with manually built newer GCC versions which significantly improve cpuminer performance) If you love performance use recent software...
  18. I guess this script will never work on rock64: it has a RK3328 SoC and Mali-450 GPU. This script instead installs drivers for RK3288 which has a totally different and not compatible Mali-760 GPU
  19. Hello everyone, got a question regarding the rock64 and the HDMI output. I installed armbian recently with the media test script provided in this board, but everytime I run xrandr, I get this: rock64@rock64:~$ sudo xrandr --listproviders Can't open display rock64@rock64:~$ xrandr --props Can't open display Xorg logs correctly identify that no display is enabled, also noted that glamor failed to start: [ 12.505] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 12.908] (II) Module glx: vendor="X.Org Foundation" [ 12.908] compiled for 1.19.2, module version = 1.0.0 [ 12.908] ABI class: X.Org Server Extension, version 10.0 [ 12.926] (II) LoadModule: "modesetting" [ 12.938] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 12.968] (II) Module modesetting: vendor="X.Org Foundation" [ 12.968] compiled for 1.19.2, module version = 1.19.2 [ 12.968] Module class: X.Org Video Driver [ 12.968] ABI class: X.Org Video Driver, version 23.0 [ 12.968] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 12.979] (II) modeset(0): using drv /dev/dri/card0 [ 12.979] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 12.979] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 12.979] (**) modeset(0): Option "AccelMethod" "glamor" [ 12.979] (==) modeset(0): RGB weight 888 [ 12.979] (==) modeset(0): Default visual is TrueColor [ 12.979] (II) Loading sub module "glamoregl" [ 12.979] (II) LoadModule: "glamoregl" [ 12.994] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 13.270] (II) Module glamoregl: vendor="X.Org Foundation" [ 13.270] compiled for 1.19.2, module version = 1.0.0 [ 13.270] ABI class: X.Org ANSI C Emulation, version 0.4 [ 13.270] (II) glamor: OpenGL accelerated X.org driver based. [ 16.509] (II) glamor: EGL version 1.4 (DRI2): [ 16.509] EGL_MESA_drm_image required. [ 16.518] (EE) modeset(0): glamor initialization failed [ 16.518] (II) modeset(0): ShadowFB: preferred NO, enabled NO [ 16.518] (II) modeset(0): Output HDMI-1 has no monitor section [ 16.518] (II) modeset(0): EDID for output HDMI-1 [ 16.518] (II) modeset(0): Output HDMI-1 disconnected [ 16.518] (WW) modeset(0): No outputs definitely connected, trying again... [ 16.518] (II) modeset(0): Output HDMI-1 disconnected [ 16.518] (WW) modeset(0): Unable to find connected outputs - setting 1024x768 initial framebuffer [ 16.518] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 16.518] (==) modeset(0): DPI set to (96, 96) [ 16.518] (II) Loading sub module "fb" I am a bit at loss since I wanted to use my rock64 as a headless server with nomachine and would love to use 1920x1080 as with ayufan builds. As expected, display info is empty on XFCE: I would really love to stay with armbian since ayufan releases are usually very experimental and armbian looks pretty stable. Is there anyone facing the same issue?
  20. Thank you for pointing that out. I finally found it. Now I'm having a new problem. When I was using an older version of MySQL, I was able to change the datadir to a new location, reset the server, and it would load the databases in the new location. Now when I change the location of the datadir, I'm getting a bunch of errors: For example, I change this: user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql/ tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking To this: user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /New_Directory/mysql/ tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking and I get this error: Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details. Running "systemctl status mariadb.service" returns this: ● mariadb.service - MariaDB database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: Active: failed (Result: exit-code) since Wed 2018-09-26 13:17:36 UTC; 1min 6s Process: 3642 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_STAR Process: 3638 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUC Process: 5747 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WS Process: 5655 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR Process: 5649 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START Process: 5643 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/ru Main PID: 5747 (code=exited, status=1/FAILURE) Status: "MariaDB server is down" Sep 26 13:17:35 rock64 systemd[1]: Starting MariaDB database server... Sep 26 13:17:36 rock64 mysqld[5747]: 2018-09-26 13:17:36 548003549184 [Note] /us Sep 26 13:17:36 rock64 mysqld[5747]: 2018-09-26 13:17:36 548003549184 [Warning] Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Main process exited, code=ex Sep 26 13:17:36 rock64 systemd[1]: Failed to start MariaDB database server. Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Unit entered failed state. Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Failed with result 'exit-cod lines 1-19/19 (END) I'm seriously at a loss here, so I would really appreciate if someone could point me in the right direction. Or even send me to a tutorial that would actually work. Things I've done so far: copied the contents of the original database director to the new one using rsync tried reinstalling and starting over from scratch tried changing the location of the .pid and .sock files done a chown mysql on all files and directories concerned created new .pid and .sock files
  21. I have been going over forum after forum trying to figure out how do this, and nothing seems to match up. I just downloaded MySQL on my new Rock64. The OS is installed on a 32GB eMMC, and I have a 1.5GB USB 3 HDD installed for my home folder and all the user data. I bought this to be set up as a LAMP server, and have installed Apache and PHP, which are working well. I haven't had any luck with MySQL though. It seems that nothing matches the documentation. All the documentation and forums say that the configuration file is located at /etc/mysql/my.cnf In that configuration file, there's supposed to be DB location settings, but it's not there. This is all I have in the my.cnf file: The MariaDB configuration file # # The MariaDB/MySQL tools read configuration files in the following order: # 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults, # 2. "/etc/mysql/conf.d/*.cnf" to set global options. # 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options. # 4. "~/.my.cnf" to set user-specific options. # # If the same option is defined multiple times, the last one will apply. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # This group is read both both by the client and the server # use it for options that affect everything # [client-server] # Import all .cnf files from configuration directory !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mariadb.conf.d/ Could anyone please help me figure out how to change the main database directory? Thank you!
  22. Thanks very much for your guidance on this. I can explain the log entries above regarding ethernet connectivity. The first entry was me having had to connect the rock64 directly to one of the fast ethernet ports on my router downstairs, which is located near the TV, as I needed the TV and a keyboard hooked up to work through the initial install process via local login. The entires you see where the ethernet port negotiates at 1Gbps is where I have now moved the rock64 to my comms cupboard upstairs and have connected it to my server LAN switch which has 1Gbps ports. Thanks for the tip regarding nmtui, I never knew this existed to be honest, as I have never really used NetworkManager as I do not run a desktop on any of my linux devices & servers, they all run headless and I manage them via ssh. I usually configure all my linux devices/servers with static IP addressing and if it is a debian based distro, then I set this via /etc/network/interfaces as suggested by the debian wiki. One other quick query if I may, what is the most elegant way for me to remove the desktop and associated packages from my current rock64 armbian install? Am I best to simply autoremove a package in xserver-xorg and hope that it then removes all associated dependencies? (Am not experienced in linux desktop configuration so am not familar with the package dependencies etc) Thanks again for all your help and support.
  23. Rock64 uses the same eMMC module as the Odroid's. These are among the best eMMC's. Very fast. I don't think they easily break. They do cost a bit. And the lower capacity ones are a bit slower. I've got 3 of them. 32GB, 64GB and 128GB. Haven't had any problem. Thumb drives I've had much trouble with. Many die quickly. Run too hot. As @tkaiser said. You have to look out very well not to buy crap. But they are cheaper in lower capacity. Make backups if you choose to use flash-drives. Another informative link to a post of tkaiser. The C2 eMMC's are the ones for you.
  24. Well, there are some kernel configs in the first commit referenced here, that we are not enabling. They may very likely be the cause for the board not booting when you enable vcc_sdio. I think it is worth giving a try. But someone else will have to test it in a Rock64 to make sure these configs don't affect it, since I only have the Renegade.
  25. As discussed on multiple threads, the aim of this thread is to bring all RockChip devices under one BSP (4.4) Kernel. This discussion can be found (partly): and a bit background here: https://github.com/rockchip-linux/kernel/issues/98 Cause I'm not willing to cut out all this stuff from the related threads (this would end in a complete disaster) I try to summarize it here (if something is missing, let me know I'll add it): RockChips BSP kernel is not longer an option. Cause it breaks faster that our current resources allow to fix it. Having all SoCs under one kernelsource would make it more predictable and decrease the efforts needed to keep them 'reliable working'. Ayufans (https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4) tends to be the preferred Kernel at the moment. First attempts to bring up rk3288 boards are made notify some of the involved people just to make sure they don't miss it (I probably miss some, don't be upset ): @TonyMac32, @JMCC, @tkaiser, @Igor, @zador.blood.stained, @hjc & @ayufan Some questions which are open for me: How can we ensure that the 4.4 kernel we currently use for the RK3288 get at least 'security updates' as long as the switch needs? Is someone in touch with ayufan so that he recognizes our idea? (or @ayufan do you read the stuff here ) Can we 'channel our efforts' to ensure that we don't waste our and others time (e.g. open a transitions branch and make it clear that PRs against the old kernels don't make sense) I hope this thread doesn't get floated with garbage but on the other side I hope that people write about their plans and 'results' so that we don't do the work twice. EDIT: BTW, I'm not sure if this thread fits better in development or here, but I think it's more recognized by the rk-users when we have it here..
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines