qstaq

Members
  • Content Count

    70
  • Joined

  • Last visited

About qstaq

  • Rank
    Advanced Member

Recent Profile Visitors

821 profile views
  1. I confused the 3399K with another RK SoC so asked a stupid question
  2. The module is there in the official build with the bsp 4.9 kernel If its missing from @balbes150 build then you can clone his repo from https://github.com/150balbes/Build-Armbian and build an image from that. When asked if you want to modify the kernel config, choose yes. When you get to the kernel config screen choose to build uas into the kernel (CONFIG_USB_UAS) If you struggle I can provide detailed instructions tomorrow
  3. Excellent, glad its working! Yes it certainly does. It should behave just the same as x86 debian / ubuntu in that regard. Are you still having problems loading the uas supported driver?
  4. There is no libmp4v2 for Buster, upstream Debian have dropped support for it. Same goes for Ubuntu in current versions. You need a Debian stretch image or an Ubuntu Bionic image if you dont want to have to compile this library yourself https://packages.debian.org/search?keywords=mp4v2
  5. @ashok are you sure you have the xplay Q? The ath10k module shouldn't be able to load on that device. It's common with TV boxes to find completely different hardware inside devices with the same name which is partly what makes them impossible to support. What DTB are you using? Can you post an: armbianmonitor -u
  6. Now it makes sense! Return your USB enclosure and get a different one. The JMS567 (152d:0578) has many known problems under both linux and windows Devices that use JMicron's own firmware function better and have some usb-quirks set in the driver to work round its UAS, power and USB detection issues. The cheap Chinese versions (Orico, Startech, etc) usually have a modified firmware that in most cases doesn't work properly, especially with linux. Linux sees the device is of 152d:0578 and expects to be talking to the official JMicron firmware but most of the JMS567 devices don't actually run this firmware Google search for "JMS567 152d:0578 Linux usb3 error" and you will find literally hundres of people having the similar type of issues as you https://github.com/raspberrypi/linux/issues/3026 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789589 https://www.raspberrypi.org/forums/viewtopic.php?t=246989 https://forums.linuxmint.com/viewtopic.php?t=230562 You might get basic functionality by disabling UAS and playing around with different usb-storage quirk options but it's a bridge chip that has serious problems in most of its implementations and really the only good place for it is the bin
  7. @ashok When booted into Armbian what is the output of: dmesg | grep -i firmware lsmod | grep 80211 WiFi is a mess on a lot of the TV boxes I have played with and for a lot of devices its just not worth the effort. Even when it works, it usually doesn't. Also the armbian-firmware package seems to have some of the firmware blobs in the wrong locations for devices that use brcm blobs
  8. Wow this thread expanded Sorry for no reply, Ive been away with work After reading through your problems I have realised a problem with my advice. My own Armbian builds (and balbes150) use a separate boot partition whereas Armbian's official N2 build does not. This means the boot.init are in the root of the first partition of the uSD, eMMC or USB SSD and is detected by both petitboot and balbes 0.4 u-boot image defaults @Viald I have just tested this again with balbes latest u-boot and with a Samsung 860 Pro SSD and a 2.5" mechanical HD both in a USB3 SATA enclosure. For both devices its working as expected (both the official Armbian N2 build and @balbes150 AMLG12 build 5.98 disco image) Maybe you have too many USB devices plugged in and dont have enough power left to properly initialise the your SSD? Can you try with all the other USB devices removed and the SSD plugged directly into the N2 (no USB hub) and see if you still get: "0 Storage Device(s) found" And also what is the bridge chip in the USB <-> SATA adaptor that you use? (lsusb e.g. Bus 001 Device 004: ID 152d:2339 JMicron USA Technology Corp. JM20339 SATA Bridge)
  9. Yes. Its simple on the N2 You can use HardKernel's Petitboot SPI Image to kexec boot from the SSD (https://wiki.odroid.com/odroid-n2/os_images/petitboot). Make sure you have the latest version of HK's Petitboot image (dev.20190705) flashed to the SPI chip, earlier versions have some problems. You can then set SPI as the default boot option and then boot into petitboot and set the ssd install as the default or only boot option. If petitboot cant find a uSD or eMMC installation, it will autoboot from the USB/SSD install regardless A better, but unsupported, option (the ability to boot non-kexec kernels and a much simpler boot process) is to flash the SPI with @balbes150 odroid-n2 SPI u-boot image from here: https://yadi.sk/d/pHxaRAs-tZiei/UPDATE_U-BOOT_odroid_n2 Prepare the SPI boot recovery image update from the HK link above on to a uSD card. Before you flash it replace the 8MB spiboot.img file that got created on the uSD card with the spiboot.img from the balbes150 yandisk repo. This will leave you with an easily configurable u-boot running from the uSD card which allows you to boot a kernel from uSD, eMMC or USB
  10. 1.9G for read and write? In which case it must using NEON instructions now. That's good
  11. Oh well, that's just a bonus then Just out of interest, did you write test the zram performance? And what compression algorithm are you using? I've had some strange performance issues with zram on Arm v Power7/8 v Intel Arm seems to be the only modern platform where LZO and LZ4 are not hardware accelerated. I don't know if this is a limitation of Arm's NEON vector extensions or if nobody got round to implementing vector instructions in the Arm ports
  12. Interesting stats Surprised that a 256GB NVMe drive only has 2.5GB or 1% of its capacity as fast flash and then the rest is QLC I presume? What model is it? Seems a bit of a con to have an NVMe drive that throttles down to half SATA speeds once the MLC buffer is full
  13. That is telling you NOT to use a separate USB Serial adaptor. Just plug a plain, phone charger style, USB A <-> MicroUSB cable direct from your PC to the devices Micro USB serial port. The board itself will then show as /dev/ttyUSB0 on your host PC when you power the board on. Do not use a USB hub or switch or multiplier (bad ones can inject 5v power that you really dont want at this stage), just a direct cable. Plugging a USB Serial adaptor onto these pins can damage the usb serial chip on the board if you accidentally connect the +5vcc red wire from your USB UART into the boards USB UART