qstaq

Members
  • Content Count

    70
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by qstaq

  1. I confused the 3399K with another RK SoC so asked a stupid question
  2. Hi guys, sorry for the slow response, was called out over the weekend and haven't had much time to look at things Jira has changed a lot in the last 12 months. I very much like the structure of the new simplified project layouts that are available. Very useful for tracking individual projects or sprints but possibly a little too simple for complex projects. I played with this over the weekend and couldn't make it work properly. The way its currently working is OK in that it gives some link between the issues but it has to be manually created. There are other ways to integrate github into Jira that I have used before. We created a system whereby we could assign a specific tag / label to an issue or PR and that issue / PR would automatically get replicated and tracked in Jira. I have asked a previous colleague to forward me some info about how we created that integration in the past. I have Vero coming round this evening to have a look at the integration part and structures. She has been catching up on the forum and github yesterday and is starting to grasp the basics, though she probably needs another day to get comfortable. I also told her to find this Jira thread and introduce herself and read up but I dont think she has access to view it. Can she be invited to have access to this specific thread? I would vote to leave all technical issues in github. Just pull in or reference them for specific projects or sprints, otherwise the core list in Jira can get unmanageable There are 3 main approaches to this 1) Some organisations like to have regular scheduled sprints that are planned in advance but without content. The sprint contents are planned closer to the start date and based on whatever issues / developments are pressing at the time 2) Some organisations like to have regular scheduled sprints that are planned in advance including content. This obviously requires some significant ahead of time planning from a development direction perspective. Organisations that use this structure tend to also have ad-hoc sprints for bug fixing sessions 3) Sprints are decided upon and structured in an ad-hoc basis, usually as the result of review or crisis meetings. This kind of structure tends to be better for bug fixes but not so good for development For Armbian I would think that a option 2 is better in the long run with maybe 4-6 major sprints per year for pre planned development / releases and quarterly or monthly mini sprints to deal with bug fix triage Development sprints should be releases in my opinion. Bugfix sprints should maybe be point release. Official images are built / released only after a dev sprint or bugfix sprint. Obviously that doesn't work with Armbians current versioning system but maybe that also needs a think about? +1
  3. 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
  4. 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?
  5. I also agree with @lanefu on the project manager side (I hate the term agilist, every self described agilist I have met in person has been a total bullshitter ). Maybe not necessarily a full on project manager, but certainly some kind of "whip" to keep track of and report on individual projects and how they relate to the overall project so that @Igor can spend less time analysing and decision making. Some basic aspects of this can of course be automated inside Jira but a human is still needed to decide on importance and resource commitment. I think without having such a person the project will struggle with direction I can help with planning / implementing Jira and workflows if there is a shortage of volunteers (like everyone else Im usually restricted on available time but do usually have 1 quiet week per month). I have project managed a few Jira implementations / restructures and I have been and end user for a while. If its just for internal project management with github integration, that does make the structure much simpler
  6. Sorry I meant Jira Software when I referred to core Im a fan of Jira, I think its a great system, especially with the service desk, however it takes a good amount of planning, training and workflow documentation / implementation to make it work properly. Roughly 7 out of 10 Jira setups I have encountered actually make life more difficult for contributors and end users seeking support over just using basic github tools because of badly thought out or non existent workflows. Done properly it works very well, my concern would be the resources required implement and continuously monitor and review the structure. Im not trying to be negative on the idea, I think its a great solution to the problems faced by Igor and the team. I just think its wise to be aware of the extra management overhead it will generate in the short to medium term, potentially hundreds of hours. Also a lot of the work required to plan and implement Jira properly is not specific to Jira. A lot of this extra work could probably apply to re-organising the project as it is now. An alternative (but not equivalent) option may be to break the Armbian/build project down into multiple smaller, simpler, modular projects. This would make long term management and project planning easier. Obviously this is not an optimal solution but its simpler and less resource intensive and allows contributors to understand the code structure with less effort usually From an idealistic standpoint I would say +1 here for Jira
  7. Are we talking about Jira core here? Or Jira with Service Desk?
  8. 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
  9. @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
  10. 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
  11. @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
  12. 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)
  13. 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
  14. 1.9G for read and write? In which case it must using NEON instructions now. That's good
  15. 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
  16. 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
  17. 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
  18. So why are you asking on the Armbian forum? You have an x86_64 Ubuntu problem with a device that doesnt have and probably never will have Armbian support?!? Im confused as to what support you expect to get from here sorry? Especially as you wont even provide the information asked for to try and help you... Also like I said previously, you DO NOT need a USB Serial adaptor for that board (https://www.96boards.org/product/poplar/). Just plug a micro USB cable straight into the micro USB debug port. There is a USB serial adaptor already on the board! Its the small IC next to the micro USB port
  19. This is a board that doesnt run Armbian, its a SoC that has very bad linux support. Why are you asking about it here? Are you bringing up a new csc board config? Also the board has its own USB UART built in, just use a micro USB cable straight into the micro USB port, you dont need a USB serial adaptor and it wont work with one if using the micro USB port Aside form that, you need to identify the controller on the USB serial adaptor to find out which driver it needs and your lsusb output seems to show a faulty USB hub. Please remove the USB switch from the chain. I cant help you if you wont give the rest of the info I asked for that is needed needed to troubleshoot, but it looks like you have a faulty USB serial adaptor as Ubuntu 18.04 ships with drivers for pretty almost every USB serial device out of the box and your USB Serial device is not being detected at all, its not a missing driver based on your lsusb output
  20. Ubuntu host is x86_64 or armhf / aarch64? Your lsusb does NOT list any plugged in usb serial devices What kind of USB serial adaptor? Output of: armbianmonitor -u lsusb -v ls /dev/ttyACM* ls -l /sys/bus/usb-serial/devices lsmod dmesg (if no armbian-monitor) zcat /proc/config.gz | grep USB_SERIAL
  21. It depends on the boot method and kernel you are using but a very simple way would be to have 2 boot.scr / boot.ini / extlinux.conf files (I have no Orange Pi boards and I cant remember the exact boot process for them) The following is not a great way to go about it but I was stuck in a hotel most of the weekend setting up some odroid n2 devices and and needed a quick and dirty way to set them up to tripleboot and I didnt have a serial cable. I needed Armbian, Ubuntu & my own custom distro from the eMMC and to have the option of also booting Android from uSD. I used 3 separate partitions on the eMMC to store my distros but you could easily split between eMMC and uSD instead I first created the 3 boot configs I needed then wrote a simple script to switch them. Thats it! You should be able to adapt it for your Orange Pi 3 Boot Config Armbian: # N2 Image based on @balbes150 build LABEL Armbian LINUX /Image-armbian INITRD /uInitrd-armbian FDT /odroid-n2-balbes-armbian.dtb APPEND root=LABEL=ArmbianFS rootflags=data=writeback rw console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 Boot Config Ubuntu: # Hardkernel Ubuntu build LABEL HKUbuntu LINUX /Image-hk INITRD /uInitrd-hk FDT /odroid-n2-hk.dtb APPEND root=LABEL=HardKernelFS rootflags=data=writeback rw console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 Boot Config Open-CoreStaq: # Open-CoreStaq Internal build LABEL CoreStaq LINUX /Image-csq INITRD /uInitrd-csq FDT /odroid-n2-csq.dtb APPEND root=LABEL=CoreStaqFS rootflags=data=writeback rw console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 bootmode.sh toggle script: #!/bin/bash BOOTSLOTS=`ls -l /boot/extlinux/*.boot | cut -d"/" -f 4 | sed 's/.boot//g' | nl | cut -c 6-99` case "$1" in a) mount -o remount,rw /boot cat /boot/extlinux/ArmbianFS.boot > /boot/extlinux/extlinux.conf sync && mount -o remount,ro /boot [[ $2 = "y" ]] && reboot ;; h) mount -o remount,rw /boot cat /boot/extlinux/HardKernelFS.boot > /boot/extlinux/extlinux.conf sync && mount -o remount,ro /boot [[ $2 = "y" ]] && reboot ;; o) mount -o remount,rw /boot cat /boot/extlinux/CoreStaqFS.boot > /boot/extlinux/extlinux.conf sync && mount -o remount,ro /boot [[ $2 = "y" ]] && reboot ;; *) echo "bootmode.sh mode=(a|h|o) reboot=(y|n)" echo " mode [a=Armbian, h=HK-Ubuntu, o=Open-CoreStaq]" echo " reboot [y=Yes, anything_else=No]" echo "e.g." echo "bootmode.sh r y #Set Armbian boot mode and immediatly reboot" echo "bootmode.sh s #Set Open-CoreStaq boot mode to be active for the next boot" echo "" ;; esac Edit: You can probably ignore / remove the "mount -o remount /boot" entries. They are only there because I have a separate fat32 boot partition that I like to keep un-corrupted so I mount ro for normal use Edit2: As martinayotte states, as the OPi3 gives boot priority to the uSD then thats much simpler. Have your primary distro on eMMC and secondary on uSD. Insert uSD to boot uSD, remove uSD to boot eMMC
  22. @balbes150 Thank you for your detailed response but in this case the boards are faulty, NVidia's repair centre has confirmed with the first 3 boards we had fail and blamed it on high heat conditions that the boards were operating in. Modern sgdisk calls the equivalent of sgdisk --zap-all with --clear which clears both the start and end headers. The 32mb zeroing is not for gpt but to make sure we have wiped out any hidden u-boot or android data or partitions at the beginning. I have tried new SD cards and fully zeroing the entire card, it makes no difference I'm new to Armbian / Linux and arm hardware in general but I've been working with GPT disks since AIX 4.2 and have a reasonable understanding. Unless of course GPT is different under Linux or Arm, in which case my assumptions won't work Anyway I will try again when I get back from my work travels tomorrow with a known good board
  23. GCC 6.3.0 is default for stretch. The board type is irrelevant, the GCC version comes from the parent distro, in this case stretch https://packages.debian.org/search?keywords=gcc https://packages.ubuntu.com/search?keywords=gcc