Jump to content

Search the Community

Showing results for 'rock64'.

Didn't find what you were looking for? Try searching for:

  • 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

Found 1227 results

  1. tkaiser
    XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum). Wrt new boards being interesting for NAS use cases: Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.
  2. mdel
    i'm still looking at my original z28 pro before testing linux images i have extracted the dtb from the resource partition (didn't know it was there with rockchip) and converted it to dts. It's not easy to read as "aliases or defines" are not there anymore and everything is in hex. but it should be intesresting to compare it to rock64 dts to see hardware configuration variations. One thing i'm still not sure about is if that dtb (from the "resource" block) is actually used by the box at boot or if there's another dtb somewhere.. here's the boot serial output : rk-kernel.dts.zip
  3. tkaiser
    Well, for the +100 MB/s you need a good OS image taking care of settings (those images that don't care about settings/versions perform really low as NAS) and I really hope Hardkernel now ships with a better USB cable to interconnect both devices. If you can solve the USB3 connection hassles then XU4 is not the worst choice to be combined with 2 USB3/UAS capable disk enclosures (the internal USB3 hub doesn't matter when you connect HDDs, that's only a performance drop noticable with SSDs). Besides XU4 you've currently not that many options if it's about really fast storage and 2 HDDs at the same time. ROCK64 would need an external USB3 hub, those mPCIe equipped boards combined with an ASM 106x or Marvell 88SE9215 are an option or Helios4. Next year will get more interesting since a few more boards with good storage capabilities will be available.
  4. trohn_javolta
    .... so much info in so little link. Thanks for that....For me as a beginner the XU4 Cloudshell 2 combination seemed perfect + on their website they advertise copy speeds via network of ~ 100 mb/s and nothing about loose connections etc.. Well, now I'm exactly where I started off.... Btw. thx also for the insight about sd,hdd and emmc performance. This all confirmes my decision to stay with armbian as os. But now I again don't know which hardware I should use. Pardon me to get off topic but since it seems to me that you're the "diy nas" expert here I want to ask for your advice I have too much devices lying around (probably you have more lying around ) and plan to replace them with...well..idealy one SBC and an enclosure: -) WD My Cloud 6TB, single bay NAS (I'm unhappy with the os, I just needed a new HDD and it was a good offer) -) "old" 3TB HDD in external USB 3.0 enclosure hooked up to NAS via USB port -) Hummingboard i2eX (you're probably familiar to that board) working as my home server -) dirt cheap S905X china box running libreelec working as my media center I think I will stay with the S905X box, it works really good with libreelec. All other devices should be replaced. I would like to take my two hdd's, put them in a case along with a SBC and use this as a NAS/homesever combo. File transfer of ~ 100-110 mb/s via gigabit lan would be really nice. The homeserver is running dl/torrent servers like transmission, nzbget, jdownloader2 | managers like sickrage,radarr,htpcmanager and also unrar at a decent decompressing speed would be nice. All of that + NAS functionallity...... Do you think it's doable or am I dreaming of an "egg-laying wool-milk-sow"? The Rock64 seems promising, but do you think it will be able to handle the homeserver jobs?
  5. boobypi
    According to this - always some issues - https://github.com/ayufan-rock64/linux-u-boot/commit/73faad8aeba3fc5a416c86a003cdb627fb24b624
  6. tkaiser
    Undervoltage, it seems you forgot that the Tinkerboard is a pile of crap you can switch off even with light loads. Wrt the S905X benchmark results unfortunately I miss distro and clockspeed info. Based on the information I assume it's Ubuntu Xenial y la patata is running at slightly above 1.4 GHz These are your results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 172077.88k 476222.74k 796116.22k 989857.79k 1065203.03k aes-192-cbc 166314.77k 410735.66k 636071.94k 756757.16k 800991.91k aes-256-cbc 159311.97k 370863.64k 544318.12k 630333.78k 660720.30k And this is ROCK64 at stable 1.3 GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k Smells like 1.3 GHz vs. 1.42 GHz (and not 1.5GHz). Would be great if someone could provide tinymembench results too. 7-zip numbers are not that great since even an RPi 3 at 1200 MHz performs at this level. Strange.
  7. boobypi
    Equation for board with SDIO wlan and bluetooth, no gmac: the SDIO module is wired with a full uart RTS CTS (UART0 | UART1) for Bluetooth and a sdmmc (SDMMC0 | SDMMC1 | SDMMC0_EXT). UART1 is multiplexed with SDMMC0_EXT. UART2 has a pin switch (UART2-0 | UART2-1). UART2-1 isn't multiplexed with SDMMC0. SDMMC0 available. UART2-0 is multiplexed with SDMMC0. SPI2 is multiplexed with SDMMC0_EXT. I see four possibilities : - The console is UART2-0 (multiplexed with SDMMC0). SDMMC0_EXT and SDMMC1 are dedicated to the SDIO module. Boot possible with an SDMMC0 sdcard but loss of the UART2 console. => (maybe an idea about bug boot with uart connected) - The console is UART2-1 (not multiplexed with SDMMC0). UART1 (disable SDMMC0_EXT) for serial bluetooth, SDMMC1 and SDMMC0 are dedicated to the SDIO module and SD socket. Boot possible with an SDMMC0 sdcard. - The console is UART2-1 (not multiplexed with SDMMC0). UART0 for serial bluetooth, SDMMC1, SDMMC0 and SDMMC0_EXT can be dedicated to the SDIO module and SD socket. Boot possible with an sdcard if SDMMC0 is available on sd socket. Boot possible with an spi nor flash if SDMMC0_EXT is available on sd socket. - The console is UART1 (multiplexed with SDMMC0_EXT). UART0 for Bluetooth, SDMMC1|SDMMC0 for sdio wlan. SDMMC1|SDMMC0 for sd socket. Boot possible with an SDMMC0. - The console is UART0. UART1 (multiplexed with SDMMC0_EXT) for Bluetooth, SDMMC1|SDMMC0 for sdio wlan and SD port. SDMMC1|SDMMC0 for sd socket. Boot possible with an SDMMC0. As information ROCK64 use UART2-1 for serial console. Sorry for brainstorming but it's needed to make the right uboot with output on right serial console
  8. Goerlitzer
    My question to the developer: Is there any probability that the native ethernet (gigabit) connection will be working in the future? I think that's the main advantage of the rock64 board (gigabit ethernet AND usb 3.0). Otherwise many other boards will work as well as NAS as the rock64. Thanks in advance for answers!
  9. tkaiser
    This can only happen if /var/log/armhwinfo.log is either missing or empty. Did you also start to delete log files? Since it just works? This thread now has 23 posts and all that would've been needed is Booting Armbian image Insert wireless dongle (2 seconds waiting) nmtui-connect If driver is contained in the kernel and if firmware is contained in armbian-firmware package (as in your case) Wi-Fi is up and running after this (and if not 'armbianmonitor -u' output is needed). No need to fiddle around in config files and with interface names people seem to hate (and not understand). If you love to configure Linux networking the anachronistic way (you call this 'standard' for reasons unknown to me) you can always do so. Just waste some hours of your live to get an idea how to get back primitive interface names (wlan0), how/why some wireless network adapters appear as more than 1 device by default (RealTek's p2p0 you see above for example), how/why network manager and Debian's/Ubuntu's 'classical' interfaces stuff interfere and how to deal properly with link status changes. As with every task you can spend hours on stuff that could be done within seconds --> nmtui/nmtui-connect. BTW: the driver contained for the dongle spits out an awful lot of messages. Might be worth to open an issue at https://github.com/ayufan-rock64/linux-kernel to lower verbosity for drivers below drivers/net/wireless/rockchip_wlan/
  10. tkaiser
    Hardkernel/Jmicron released a firmware update tool here https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update (archived and contents mirrored at http://kaiser-edv.de/tmp/tAm6om/jms578fwupdater.tgz) It seems this firmware update does NOT solve the real problem (the bridge not behaving SAT -- SCSI / ATA translation -- compliant but doing its own thing). I checked firmware versions of the onboard JMS578 on my HC1 (/dev/sdb) and on ROCK64 SATA cable (/dev/sda): root@odroidxu4:~/JMS578FwUpdater# for i in /dev/sd? ; do echo -e "$i: \c" ;./JMS578FwUpdate -d $i -v; done /dev/sda: Bridge Firmware Version: v0.4.0.5 /dev/sdb: Bridge Firmware Version: v0.1.0.5 So JMS578 firmware version on the ROCK64 thingie is way higher than HC1's internal but firmware update does only provide a new 'JMS578-v0.1.0.5.bin' version. Now updating firmware on HC1 with newer 0.1.0.5 firmware, setting 5 min spindown timeout and backing up old firmware: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -f JMS578-v0.1.0.5.bin -b ./backup.bin -t 5 Update Firmware file name: JMS578-v0.1.0.5.bin Backup Firmware file name: ./backup.bin Auto spin-down timer: 5 min. Backup the ROM code sucessfully. Programming & Compare Success!! Backing up the ROCK64 SATA cable firmware seems to work too: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -b ./backup_0405.bin Backup Firmware file name: ./backup_0405.bin Backup the ROM code sucessfully. Open File Error!! root@odroidxu4:~/JMS578FwUpdater# ls -la backup* -rw-r--r-- 1 root root 50688 Nov 1 19:34 backup_0405.bin -rw-r--r-- 1 root root 50688 Nov 1 19:31 backup.bin I think I'll wait for the next firmware update that contains a real fix (JMS578 becoming SAT compliant) since with this firmware the chip is still broken: root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown
  11. mdel
    "logging in" after you flashed a linux image on the emmc, right ? i'm still investigating the stock android features at the moment so i haven't flashed anything yet. i don't quite understand how sdmmc1 (not bootable sd port, according to the datasheet) would be used on this device, when those pins are shared with the gmac bus which is activated on the z28 pro with gigabit. Also seeing that the same routing exists on the rock64 schematics (gmac pins + rtl8111) and sdmmc1 is not routed on the board. there are also some sdmmc0_ext pins i don't quite understand the purpose in the datasheet. I will extract the android dts and compare it to the rock64 one or to a z28 (not pro) one if i can find any, but i still don't know how dts really works and if you specify which sd port is enabled, or only that "there's a sd card port on the device".. Anyways i can't interrupt uboot and even if i could there's always a chance you can't input anything, as seen on other devices. I was hoping for a extremely favorable uboot with pxe boot =)
  12. inos
    I have built a rock64 stretch image and found in syslog: localhost cron[757]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) could be fixed with: sudo chmod 644 /etc/cron.d/armbian-updates
  13. tkaiser
    Driver and firmware are two different things. With ROCK64/RK3328 we currently use a 'vendor kernel' and Rockchip added a bunch of Wi-Fi drivers to their kernel sources. Part of Armbian images is an installed package 'armbian-firmware' which should at least address onboard adapters and most common dongles. So all that should be needed is nmtui-connect, done. No need to fiddle around with interfaces files and names. There's a reason we recommend using nmtui-connect (since usually 'just works') but I have no idea how to improve the current situation that users don't read/follow this documentation...
  14. boobypi
    I jump into a hack try! Just bought an MXR10 same AX5 board but a better emmc chip 32GB 208mhz instead 16GB 103mhz. According to rock64 forum, it's possible to boot in spi mode and sdio can work with spi nor flash in spi mode 1Bit. So in theory it's possible to put spi flash in place of sdio wifi module. I will try to put openwrt on spi 16mbyte, to install linux, dump android image. I think this is why vendor put sdcard on the wrong sdio port, in order to block easy copying their android image. If it's work it's will be easy for someone to buy an spi flash, write it with an esp8266 (esptool can write 128mbit flash). The hard part is be able to boot an openwrt or an network boot from spi flash. On A5X or MX10 there is an usb hub, so i think it's possible to add an usb wifi to remplace the sdio wifi module removed
  15. richardk
    Rock64 doesn't have on-board wifi. Mine's got a Wifi USB dongle, working fine.
  16. thomasgrzybowski
    I'm trying to get wifi working on my Rock64 running the nightly server image. Is this possible?
  17. tkaiser
    Most probably not since AFAIK the kernel RK's Android uses is a 3.10.$something while the Linux images rely on 4.4 or mainline. Of course you can fetch the various .dts for ROCK64 from ayufan's repos (3.10, 4.4 and 4.14) and compare to get a clue how to adopt stuff.
  18. srx
    Not sure how to get proper DTB file. I can extract it from android but will it work? I tried with generic ROCK64 images and default DTB. I remember from LibreElec and s905x that you must use correct DTB for kernel in use. So DTB is decompiled and recompiled somehow. Not sure how. DTBs for different hardware was provided with every new version. Looks like there is something that looks like serial console under heatsink. Just up from flash memory chip. I have not removed heatsink yet because I do not have anything at hand to reattach it later.
  19. inos
    Thank's for supporting Rock64! Is there a chance for a debian server image (beta) within the near future? All my boards are running a armbian debian OS and I would like to stay consistent here... Best regards Martin
  20. tkaiser
    Why? Check https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829 for example to get a clue which advantages the more modern CPU might have if you need AES encryption (still needs real-world tests of course, the numbers there are just a comparison at 'proof of concept' level). Then these Marvell things are made for NAS and router purposes unlike tablet, phone and TV box SoCs on other SBC. CPU utilization for IO and network related tasks is often less compared to other platforms due to better internal design. But if CPU horsepower is really sufficient depends on the types of applications of course. If the box should do video transcoding or also build kernels the HC1 will outperform Espressobin of course. That's one of the reasons I still look forward to more RK3328 variants since quad-core and most probably video transcoding possible HW accelerated using Rockchip's video engine. But still lack of IO possibilities of course.
  21. tkaiser
    Well, obviously the overhead trashes performance with small chunks. When comparing the numbers with another Cortex-A7 then it's again an indication that the MTK SoC is clocked with just 1040 MHz (I would assume it's 1042). I added the numbers to our list: https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829
  22. tkaiser
    I disagree. 'USB for storage' in general is a technology best described as 'cheap consumer crap'. The USB3-A receptacle is IMO a bad joke and responsible for a lot of USB3 interconnection hassles (still looking forward to get USB-C everywhere since this connector is not such a brain-dead fail) and especially ODROID-XU4 is plagued by this (due to mechanical tolerances I guess). My personal learning from this was to try to avoid USB3-A where possible so if the device has not USB-C then an USB3-to-SATA bridge should be interconnected with the SoC directly on the PCB as it's done on ODROID-HC1 now or as it will be soon done on Cloudmedia's 'Transformer' (a stackable ROCK64 with JMS578 in metal enclosure somewhat similar to HC1 -- no infos known yet since Pine people prefer to share this only with their 'elite moderator club' at https://forum.pine64.org). But still then the usual underpowering issues are possible on devices that for whatever reasons prefer a 5V DC-IN input instead of 12V to provide stable 5V to connected disks. Me as an electrics noob found 'Nominal Animal's explanations here interesting.
  23. tkaiser
    It's not, you need different DT stuff for Ethernet. Z28 is like Rockbox and Z28 Pro should be somewhat similar to ROCK64 and 'Transformer' (the RK3328 thingie with integrated JMS578)
  24. Stuart Naylor
    Z-28 is prob more like RK3328 refererence design. Z-28 pro is prob more like Rock64.
  25. Rosimildo
    Hi all, Do we know if the DT for Z-28 is really identical to ROCK64 ? It seems folks are using a build for ROCK54, but I have not seen the DT files that describes this H/W. R
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept