Jump to content

qstaq

Members
  • Posts

    70
  • Joined

  • Last visited

Posts posted by qstaq

  1. 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.

     

    On 10/11/2019 at 1:46 AM, lanefu said:

    I couldn't make sense of the github integration.. I see the linked repos, but didn't find much documentation on how to interact with them.

     

    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?

     

    On 10/11/2019 at 10:29 AM, Igor said:

    From my perspective technical issues can remain tracked with Github. In Jira if there is benefit, otherwise this can stay. Jira for everything else. Rather then Trello/Google keep stuff.

     

    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

     

    On 10/12/2019 at 5:34 PM, Igor said:

    Yes, something like that. Next we need perhaps to define sprint length?

     

    Create 4, 6 or 12 sprints / year. Having an IRC meeting to discuss what was done, adjust upcoming time slot on the end of each? Is that realistic?

    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

     

    On 10/12/2019 at 6:24 PM, lanefu said:

    What do we want the output of a "sprint" to be.... a release, just a piece of a release?, just work completed?

     

    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?

     

    On 10/12/2019 at 6:24 PM, lanefu said:

    I definitely like the IRC idea... Its definitely something i wish we had for development and planning stuff.

    +1

     

     

  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! 

     

    On 10/8/2019 at 7:11 PM, Viald said:

    Does Armbian support UAS driver ?

     

    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. 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

     

  5. 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

     

     

     

     

  6. @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

     

  7. 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

  8. @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

  9. On 10/2/2019 at 6:48 PM, Viald said:

    I'm surprised that Qstat or others users succeed in running Armbian image with Petitboot.

    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)

     

  10. 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

  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. 36 minutes ago, constantius said:

    Step 1: Prepare the Poplar board for power-on

    The Poplar board should be powered off. You should have a cable from the Poplar's micro USB based serial port to your host system so you can connect and observe activity on the serial port. For me, the board console shows up as /dev/ttyUSB0 when the USB cable is connected. The serial port runs at 115200 baud. I use this command to see what is on the console:

    screen /dev/ttyUSB0 115200

    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

     

     

  13. 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

     

     

     

    USB Serial.jpg

  14. 21 minutes ago, constantius said:

    Hi

    Host amd64 Ubuntu 18.04 serial console input

    SBC - poplar 96 Board ARM Hisilicon- USB input or microUSB ( i have switch )

    what kind of adapter ?... no name from aliexpress just female serial adapter plug into  male serial port PC

    on the other side USB 2.0

     

     

    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

  15. 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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines