Search the Community

Taking the compress out (of the /etc/apt files), deleting the cache, rebooting, didn't make any difference. I got the source to Synaptic with the intention of trying to profile it to see where it's hanging up. I bought the Rock64 to run the latest Gimp, I frequently build stuff that isn't in the debs. I need search to work. Spent a couple days trying to build firefox with 1 GB of RAM on a Pi, had to give up. There are a lot of dependencies, you can find all of them by searching in Synaptic. The deb Rust is too old, but install that and upgrade it. My 3-line interface file seems to work fine without NetworkManager interference. I disabled it with systemctl. All I need is: auto wlx0022c0cc0822 iface wlx0022c0cc0822 inet dhcp wireless-essid Moto_lte So the interface name is always wlx and the MAC? Interesting. Hmm: rock64# pwd /usr/src/misc/synaptic/synaptic-0.84.2 rock64# grep -ir sql . ./README.tasks:database-server SQL database ./README.supported:database-server SQL database Binary file ./help/sv/figures/synaptic-repositories.png matches Binary file ./help/sv/figures/synaptic-packagedetails.png matches Oh, it's only in the examples of what Synaptic could install, I was hoping there was a plan to convert to SQL or capability to export to SQL. Seems to be abandoned since 2012, the mailing list has been dead so far, no answer to the question I sent to it yesterday. Ughh, I'm getting texlive (1 GB) because I needed xmlto.

I don't use any Intel machines, my "big machine" is a Pi. I was hoping the Rock64 would be. I have a SD with Raspbian around still but for 3 weeks or so I've been running this arm64 Buster image. It's pretty close to perfect, very stable, no surprises. https://people.debian.org/~stapelberg/raspberrypi3/ Sounds like he doesn't want to go on maintaining it, it's dated 2018-01-08. I've been doing updates and upgrades, which work fine. In the sources.list are buster and unstable. Runs on Pi hardware only though, I'm on a 3B. One thing I haven't tried is just deleting/moving the cache file and letting it get replaced. I'll probably also turn off compression, but it's an option in at least 2 or 3 places. Just looking at the arm64 Pi's files in /etc/apt there's no mention of compression. NetworkManager is about to get the axe I think, I don't like that or wicd. It should have been able to run headless overnight but it kept dropping leases, I couldn't ssh to it. I just use a simple interfaces file. I don't have a USB KVM switch so only one machine gets hooked up at a time.

On Intel machine with SSD or on the same hardware with SD card? This would explain the diff. Rock64 has not a matured kernel support yet which means it can be anything while userspace is not much changed. We use upstream Debian base + few optimizations on the top which, I doubt, has anything to do with this.

I'm running Armbian on a 4 GB Rock64, downloaded and installed yesterday. I've been using Debian/Raspbian/Armbian for about 10 years and I've really come to rely on Synaptic for searching and being able to make download scripts. Not every day but about once a week especially if I'm setting up something (like this Rock64). This Synaptic's access to the package database seems incredibly slow. A single search may take 20 minutes. After installing something it reloads the list and shows it on the screen, that can be another 20 minutes. During this time it's got 1 thread using 100% of one CPU. Typing is sometimes impaired, window repainting usually. In this picture Synaptic was behind Firefox and I clicked on it to bring it to the foreground. That still hadn't happened here (it finally did) and I wanted to screenshot it, so there are also bits of the screenshot utility being dragged off the screen. Synaptic's using too much CPU for the screen to be redrawn. From my database experience it reminds me of one time I forgot to build an index on a table. It can still be searched but very slowly. Every access requires reading the whole thing over again. I always thought it was strange there wasn't a normal SQL database somewhere, /var/cache/apt/pkgcache.bin may be it: rock64# file pkgcache.bin pkgcache.bin: APT cache data, version 11.0, little-endian, 68706 packages, 102453 versions But I don't think it's possible to use the nice GUI editors like for PostgreSQL, MySQL, SqlLite on it. The page in Firefox was an interesting article at https://unix.stackexchange.com/questions/383999/why-are-some-packages-not-available-in-my-debian-jessie-installation about fixing some apt/synaptic problems but didn't help in this case. Oh, and I'm now subscribed to the mailing list synaptic-devel@nongnu.org but I could be the only one. The last Synaptic changes were in 2012. The problem seems peculiar to Armian, Synaptic works normally in Raspbian and Debian Buster. Could be file permissions (but not obvious) or some PAM/Selinux/Apparmor thing. The FileMagic (https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_numbers_in_files on this pkgcache.bin is DC 76 FE 98.

Problems in our world are mostly below OS level and below u-boot. You don't have such problems in RPi since Linux is running inside closed proprietary OS and since kernel support is matured and supported by a huge community. If you know something about Linux, you will not learn much new with RPi. Most of the thing works and everything is pretty much the same on all versions. With Rock64 or any other board (family) things are different. They are usually further different when you move from old closed to new open or closed firmware. Booting process for Rockchip: http://opensource.rock-chips.com/wiki_Boot_option Allwinner: http://linux-sunxi.org/BROM Amlogic: https://fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html ... Userspace is the last thing you need to worry about. It can be improved but in general, its fine. In most cases, you need to fiddle with kernel/u-boot, once you leave commodity and simplicity of Raspberry Pi. That is the reason why Armbian (build script) started. To make this process as simple and as generic as possible even we have a huge diversity of ARM world. Then try to port the driver from Rpi to Rock64 kernel and it will work here as well. It can be done but it is some work. Again, our build tools provide an environment for this but it is still some work.

For a couple weeks or so I've been happily using Stapleberg's arm64 Buster raspi image at https://people.debian.org/~stapelberg/raspberrypi3/, was wondering about doing that with the Rock64 if all else failed. I found https://github.com/rockchip-linux/rkbin for firmware and hopefully drivers. I've used debootstrap before but lucked out and didn't need to put any machine specific stuff in. I have no experience fiddling with the way arms boot: uboot, etc. Hopefully I've got default.target symlinked to multi-user.target now so next time I try to boot I can at least see what's going on. I think the only thing I changed was the interfaces file, I'm not sure why I get a black screen. PAM hates me. I 'd rather watch the bootup messages and type startx anyway. I've got a few rtl8192s, this one didn't work reliably with Ayufan's Debian either. They seem to work in Pis OK. I have 2 downstairs on a Pi and Zero that are mining away through them. The names, yeah, I saw that page at freedesktop.org. I thought in my dmesg it was using a name like rtl8192cu but that's not what ifconfig shows.

On a Pi when do this you need to make a couple changes before it will boot. The drive will probably become /dev/sda (with partition numbers). Mount the drive so you can work on it, then edit the /etc/fstab (the one on the hard drive, not the one on your sd card. The perspective is about to change, instead of root being on something like /dev/mmcblk0p2 it's going to be on probably /dev/sda2. Change that in fstab. See the fstab man page if in doubt. Unmount the partition when you're done. I don't have my Rock running right now but if it has a boot partition you need to edit cmdline.txt (again,be sure it's the one on the hard drive, not your sd one). So mount the 1st partition (/dev/sda1 probably). Open cmdline.txt in your text editor and where it says root=/dev/mmcblk0p change that to root=/dev/sda1. Unmount the partition. I've seen my rock64 under Ayufan's Debian and Ubuntu, both had 7 partitions, I don't know if that's common. Most everything was in the last one, look at the sizes. I had mine working but there seems to be some sort of timeout in the USB hardware on my Pi. When I walk away for 10 minutes or so it disconnects. Different operating systems, an SD card in a reader instead of a hard drive, same thing happens. Usually a crash and whatever was mounted needs to be fscked. So I boot from SD, keep important stuff on the hard drive. Good for changing operating systems or computers, just plug it in and mount it. I plug it into my Pi or my Rock64, works the same. Handy once you get used to it.

Hi Santopol1 and Osiris, thanks for confirming, so I am not the only one, as one start doubting when being the only one. Osiris, for the support guys interesting I guess : Your answer could, perhaps, possibly suggest, not exclude, that you had Armbian on Rock64 1GB work with older images ? If so, around what date / version did it stop working ?

Hi Igor, It was late yesterday, so just to be sure I was not dreaming, I did a restart : I use Rock64 to replace Orange Pi 2E Plus as headless server with Docker as a platform for multiple applications, and looking at memory usage before, I saw no need for more than 1GB to be honest. I use 5V2A and 5V3A supply, a few Samsung 16GB Evo+, etcher, that work fine with OrangePi I have 2 Rock64 1GB, and used the current images from https://www.armbian.com/rock64/ None of these 3 work on either of the 2 sbc-s : 1. Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop 2. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img 3. Armbian_5.44.180515_Rock64_Ubuntu_bionic_dev_4.17.0-rc3.img After testing with Armbian, I used the Pine64 bionic-minimal-rock64-0.6.44-239-armhf.img on the same SD card, sbc, supply, and that boots and seems to work fine on HDMI and ssh. Let me know if you need more info / testing. Results : So I see "Found U-Boot script /boot/boot.scr" but before that there are also errors/warnings, but I am not sure if that is supposed to be like that. I think the output is the same, but for completeness : 1. 2. 3.

Hi guys, same problem here as matteobp 2 messages up, Rock64 1GB in boot loop ( same output found on UART ) I tried 2 1GB Rock64 devices, both same problem. Believe me, I know how to install Armbian on Banana/Orange pi and loving it :-). using etcher etc. I have over 20+ running using Docker, TvHeadEnd, SATIP, NodeRed MySQL servers, etc etc. The Pine bionic-minimal-rock64-0.6.44-239-armhf.img works The Pine OMV from works ( nice and fast file transfer, 80MBps, and with usb 3.0 hub, got my 4 HDD NAS working.) But I want Armbian naturally on all Pis ( OK not Raspberry, I understand and agree ) I tried 8 Armbian images so far, but all failed. Coming days I can try more if not all ;-( to see if one does work ) I see above, that Igor says, the standard images work for him, but perhaps he is not using the 1GB Rock64 ? Could that be the problem ? I had 2 times, that minicom stopped after "DRAM" and no size, but stopped. Is there newer / older hardware ? My board says : Rock64 V2.0 2017-0713 no eMMC fitted, no jumper ( tried with, no success either) I tried the current images (https://www.armbian.com/rock64/) and Armbian_5.46.180602_Rock64_Debian_stretch_dev_4.17.0-rc6.img and a few others No succes. Please dont get me using Rock64 without Armbian ;-)

I'd rather recommend ROCK64 with some USB3 multi-bay HDD enclosure. Since GbE is the bottleneck anyway, unless you've got something like Ethernet link aggregation, but that's beyond the topic of 'cheap' NAS.

Well, actually, according to the documentation, the module should choose dinamically the right DRM driver among the supported ones. But the fact is that Ubuntu packages divide the driver into two modules, one for exynos and the other for pl111. The generic "xserver-xorg-video-armsoc", in Ubuntu, is just a meta-package that will install "xserver-xorg-video-armsoc-exynos". I have tried this driver in other non-exynos SoC's and it didn't work. At the same time, the driver has so many forks that it is difficult to make general statements. For example, the version forked by Rockchip seems to be backwards-compatible with the original "generic" version: I tested it on the XU4, and it works, though performance is noticeably worst than the driver we are using in this script. This driver has been further patched for the Rock64, and it can be interesting for RK3328 boards (I'll dig more on this when I get my Renegade). The version we are using in this script is yet another fork, based on the Ubuntu version, made by CrashOverride from the Odroid community. It adds some very interesting features, such as G2D acceleration support and fullscreen Vsync. I'm not sure if these mods can be ported to other versions of the driver, but simply using it as-is in another SoC won't work, as I pointed above.

OK. I have an idea, but it's one that honestly a dual NIC board (Rock64 with expansion board, etc can do, and that's hook up my HDHomerun to a TVHeadend server directly, keeping their traffic off of the main network. To use both of the ones I have 3 adapters would be good. Possibly to play overseer on a small cluster of boards? Seems an academic use at best though. Still, it does seem interesting

https://github.com/ayufan-rock64/linux-build/blob/master/recipes/overclocking.md

That's what 'known issues' are for.. We can't avoid that people will not notice it but that's also true for all the boards we currently support. For me, there's no reason to provide the BSP kernel for new boards anymore. IMO the goal must be to get the BSP kernel dropped, as soon as the VPU works on mainline. Then, the only use case which comes to my mind for the BSP kernel would be 'camera' but the last time I looked into it, camera (ov5640 only cause there's no mainlinedriver for the gc2035) on mainline seems to work too (somebody here ever tried it here?). Adding more boards to the BSP kernel would only mean that we have to convince more people that they should switch to mainline as soon as we drop the BSP kernel. Armbian got popular... (I'm one of the guys dropped into it when H2+/H3 boards worked more or less without major issues). Cause initial boardsupport was relatively easy in the past for H3 boards (add a board.conf, fex-file, patching u-boot with adding one defconfig more, mostly copy paste from another one - as long as it isn't a BPi-M2-Zero ) adding more boards was easy, armbian gets more popular --> more boards of the same SoC came to the table. Maintaining all those H3 boards is what needs a lot of resources. More or less every boardmaker selling H3 devices writes the Allwinner specs for the SoC (maybe possible with Android, I don't know, I don't care) and not "what is possible/works with Linux" on their boarddescription, so most people. And people don't do research first for a board which cost 8-20$, they buy it and they expect that this works. Why not? The Raspberry was able to play Kodi with minor issues ~2012, so why should a board which is sold in 2018 not be able to do what's written in the description (don't hang me on the exact date, I'm to lazy do to the research when the RPi was able to run Kodi 'smoothly' )? I can somehow understand people that this should work in 2018. To lazy to go through all boardmakers (I think friendlyarm doesn't advertise 'videocapability' but I can be wrong)... What about: Having them as .csc until one of the GitHub maintainers decide to take care/responsibility for it (doesn't mean that the others should avoid working on/with it, but that at leas one maintainer knows how good the board works/ what's currently not working etc.) all CSC boards have their separate patch folder so that they can't harm board we support (may need some rework of patches when they get moved to wip or supported) but then the maintainer decided to take responsibility for that new board knows what to do. I think even boards which are initially supported by a maintainer should start as csc first, to get 'a feeling' if it's worth to level the board up to wip or supported.. People expect active work on wip boards and we have currently 7 boards (master branch) which are labeled wip (rock64 will switch to supported, and olinuxino A64 disappeared in development). Do we have (at the moment) enough resources to bring more boards to wip (isn't there some work related to the merge of development --> master which might be of higher priority - I happily help with everything I committed to the dev branch)?

SoC's have built-in support for changing frequency, generally. So the "Magic" is a driver controlling a clock generator/multiplier. However, most of the time, with reduced frequency you can reduce operating voltage a little bit to save on power and reduce heat. In this case that isn't going to be an option, on the Allwinner-based boards that support it it's a bit of a hack in the first place, using a transistor on a gpio to change the target voltage of the system regulator by adding/removing a resistor from the regulator's "voltage setting". This board does not support that. On a board like the Tinker, Renegade, Rock64, there is a matched/recommended regulator chip PMIC that takes commands and adjusts the voltages accordingly in a much more controlled fashion.

Nope, I won't spend time on this. But since the differences compared to Rock64 are negligible and the only potential Con (powering via Micro USB) can be addressed by adding a warning to the download page I vote for giving the board WIP and later supported status if someone wants to maintain it.

I would prefer to simply pull in the needed bits from Firefly repos but otherwise treat the Renegade just as another member of our rk3328 $BOARDFAMILY relying on ayufan's repos for everything else as we do it already with Rock64. The only differences between both boards are DRAM (initialization) and a few DT bits.

Quick look at network, powering and USB situation (using Firefly OS image / kernel). We have the same annoying xhci messages as on Rock64 (full dmesg output) and also no UAS on USB2 ports. Switching to performance cpufreq governor, mounting my usual EVO840 in a JMS567 enclosure running the usual iozone stuff: random random kB reclen write rewrite read reread read write 102400 4 15831 23674 26796 26832 16945 23613 102400 16 49364 67209 74121 74910 58977 67366 102400 512 276872 286532 297002 306256 296619 301503 102400 1024 302448 315207 318405 329250 321060 320937 102400 16384 337756 340906 347968 359887 359601 339523 1024000 16384 355290 358703 359438 360631 Performance numbers with Rock64 with preliminary kernel support back then (!!) here: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=34185 I power the board through Micro USB as designed but using one of those great Micro USB cables from FriendlyELEC. PSU is 2A rated. A 2.5" HDD in an ASM1153 enclosure is connected to an USB2 port, the EVO840 SSD in the JMS567 enclosure is connected to the USB3 port. Both disks powered by the board. On each disk our usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' call is creating load from the USB consumers (9W), then I added a cpuburn-a53 task. Board rebooted when my Powermeter showed 13.7W consumption which is way beyond Micro USB specs (9W / 1.8A max) and my PSU's (10W / 2A). As expected the board rebooted after ~20 seconds due to underpowering (my PSU being too weak and/or voltage drop -- too lazy to measure for this since it's the vendor's job). Fortunately the board can be powered through the GPIO header too (@ces did a great PSU mod allowing to use a 4A PSU with the GPIO header using pins 4/6 to power the board). Repeating the test my powermeter reported +16W with both disk benchmarks and cpuburn-a53 running in parallel but no problems occured at all. Quick look at network performance: GbE can be fully saturated as expected:

Thanks to @ces who donated his RK3328-CC out of frustration the board is lying now on my desk. Tinymembench numbers with kernel 4.4.114, Debian 9 from Firefly and 1.4 GHz: https://pastebin.com/5CJ94dk6 OpenSSL numbers confirm the 1.4 GHz (same numbers as NanoPi Fire3 and slightly faster than Rock64 clocking at 1.3 GHz) type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 94490.89k 298985.71k 628713.13k 899772.07k 1029215.57k 1038346.92k aes-192-cbc 90576.25k 270158.63k 520800.85k 699573.25k 776418.65k 781172.74k aes-256-cbc 88150.68k 251416.41k 456345.09k 588011.52k 641419.95k 645251.07k I would guess bootloader blobs (DRAM initialization) can be found here https://github.com/FireflyTeam/rkbin/tree/master/rk33? Edit: decompiled rk3328-roc-cc.dtb, seems it's based on rk3328-roc-cc.dts and includes over there.

I see that we boast about the number of single boards I have: VS Mecool RK3399 FireFly RK3399 OrangePI RK3399 , Odroid XU4 Asus Tinker MIQI Cubieboard 4 Khadas VIM2 FA NanoPiM3 Rock64 Odroid C2 FA NanoPI K2 Khadas VIM1 Minix Neo X7 Cubieboard 5 BananaPiM3 Pine H64 , Le Potato, Renegade from Libre computers , Orangepi Lite 2 Orangepi OnePLUS RaspberryPI 3+ OrangePI Prime OrangePIPC2 Pine A64-LTS OrangePI WIN PLUS BananaPIM64 Pine 64+ FA NanoPIA64 NanoPIM2 BananaPiM2Ultra OrangePi2PlusE OrangePi2 BananapiM2+ Odroid C1+ Hummingboard BananaPiM2 RaspberryPi2 Olimex Lime2 Creator CI20 , ( Nano pi K1 plus - iam waiting for delivery form china. ) I use it in production on a daily basis tasks and I can tell every model which one is sucked up, which overheats, does not hold the cpu clocking that the image that works on it. I can also say a lot about micro-SD cards. I use finally only sandisk and samsung.

So, the Odroid-C2 is still a very relevant piece of hardware, I'm not sure if you're going to get a (significant) performance boost by moving to another board today. For USB3 you have a very small group of SBC's including the ODROID XU4/HC1/HC2, and the Rock64 that have decent support. (I'm not 100% on the newest Allwinner stuff, it's a weak spot in my portfolio) Odroid XU4 family (like HC1): 32-bit 8-core HMP (4 fast and 4 slow cores) 2 GB RAM (LPDDR3) USB3 (HC1 trades USB3 external with a USB->SATA adapter) Gigabit Ethernet eMMC available Rock64: Same basic speed as C2, design-wise (64-bit quad-core a53) up to 4 GB RAM USB3 Gigabit Ethernet Available eMMC Pi Form Factor (like the C2) Some boards on the horizon should be quite a bit more powerful, but they're still either in very early release or as yet unavailable. For what it's worth I run my Plex server on an XU4, it can transcode a stream at a time in software when necessary. With @JMCC's work on multimedia things, I am going to give Emby a try, as I can use a custom ffmpeg with it, unlike Plex where it's "stuck" at whatever they have compiled (Indeed IIRC there was some debate about their compliance with FOSS licensing early on).

Maybe they claim the Armbian based on chip RK3328 that it´s already supported by Armbian throught Rock64. My reason to start do learn about boards it´s the posibility to split one server from my home into some parts - I call that modularity.

The sad part is, given the capabilities of the Rock64, this should be a good device, it is possible it would be interesting enough to support if we had reason.

If i long press the recover button a screen with Rockchip appear and stay on screen. That it´s the maskrom isn´t did? But nothing it´s happened if put the usb stick inside. I´d tryed with ubuntu server for arm, debian minimal and X( lxce) for arm, dietpi for rock64 and no luck. Tnx