qstaq

Members
  • Content Count

    70
  • Joined

  • Last visited

About qstaq

  • Rank
    Advanced Member

Recent Profile Visitors

874 profile views
  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