Igor

Administrators
  • Content Count

    9836
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Posts posted by Igor


  1. 18 minutes ago, q4a said:

    with 4.4 kernel

     

    On 3/22/2020 at 5:03 PM, q4a said:

    Can it be related, that I'm using HDMI-to-VGA adapter?


    With this TV you can probably only use Armbian with 4.4. kernel due to HDMI 2 VGA adaptor. Modern kernel is also slightly more power hungry which could make troubles. A device for 1 USD http://amzn.to/2wbNkLp would safe us hundreds. Get one and show boot logs on console.

     

     


  2. 7 minutes ago, bezyr5lvfk said:

    One more question, there is also an NVME extension board available connected via PCIe. I couldn't find any direct information, but from what I found, if one wants to boot from the NVME, one does still need an SD card for the boot partition, but can place the system on the SSD. It is not possible to boot completely from the SSD without any SSD or eMMC, right?


    No, you need eMMC or SD or SPI.

    Also beware that all RK3399 boards have not fully matured support, mainline kernel is here but there are bugs here and there, sometimes we break some functionality, not exactly critical ... but if you want to have latest and greatest, this is the price you have to pay. By the time you get the board, some of the current problems will be fixed anyway ;)

     


  3. 20 minutes ago, Tido said:

    Is it the download that makes it so long and if so, why does it need a download in it?


    Sources install is the slowest process. Not just download, but also unpacking, lots of small files.

     

    20 minutes ago, Tido said:

    If it is only for you, fair enough - but if testers just want to test locally their devices   and  apart from that this generates quite some load on the servers and network traffic.

     

    I plan to group tests later ... now just trying to make usable ones and create an engine. Since this is not designed for end users in first place, things like this does not matter.

     

    20 minutes ago, Tido said:

    How many user switch the kernels or need the sources - I guess most don't. 


    This tools is for analysing the situation.

     

    20 minutes ago, Tido said:

    for me it is obviously too much.


    For me, it tells very little at this point. Current tests are inside only to build a system around ... while several hundreds of testes should be the correct number. I doubt we will ever get there, but it has to be made possible.

     

    https://www.toolsqa.com/software-testing-tutorial/


  4. 1 hour ago, bezyr5lvfk said:

    This sounds like you are using the Nanopi M4 as access point yourself (or at least have). Would you mind sharing your hostapd.conf (or create_ap.conf)? That would be really awesome!


    Sadly, I do everything else but using it - actually I was using it as AP during the holiday and I don't recall any troubles (2-3 clients max) :) I am always using hostapd configuration made by the tool I made. If I find a problem with that tool, I fix it:

    Spoiler

     

     

     


  5. 21 hours ago, martinayotte said:

    On my side, I'm planning to commit my work for Allwinner 5.6.y, since it now without RCs ...

     

    - 5.6.1 has been branched

    - i am about to sort out 8189ES and FS to be ready and remove existing patches in this PR https://github.com/armbian/build/pull/1860

     

    12 hours ago, JMCC said:

    Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64.


    Legacy kernels only, right?


  6. 1 hour ago, bezyr5lvfk said:

    I'm especially interested in that, because I want to know what performance I could expect if the Nanopi M4 is used as access point?


    AC speeds at 5Ghz, client number limitation unknown.

     

    Spoiler
    
    Wiphy phy0
    	max # scan SSIDs: 10
    	max scan IEs length: 2048 bytes
    	max # sched scan SSIDs: 0
    	max # match sets: 0
    	max # scan plans: 1
    	max scan plan interval: -1
    	max scan plan iterations: 0
    	Retry short limit: 7
    	Retry long limit: 4
    	Coverage class: 0 (up to 0m)
    	Device supports T-DLS.
    	Supported Ciphers:
    		* WEP40 (00-0f-ac:1)
    		* WEP104 (00-0f-ac:5)
    		* TKIP (00-0f-ac:2)
    		* CCMP-128 (00-0f-ac:4)
    		* CMAC (00-0f-ac:6)
    	Available Antennas: TX 0 RX 0
    	Supported interface modes:
    		 * IBSS
    		 * managed
    		 * AP
    		 * P2P-client
    		 * P2P-GO
    		 * P2P-device
    	Band 1:
    		Capabilities: 0x1020
    			HT20
    			Static SM Power Save
    			RX HT20 SGI
    			No RX STBC
    			Max AMSDU length: 3839 bytes
    			DSSS/CCK HT40
    		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
    		Minimum RX AMPDU time spacing: 16 usec (0x07)
    		HT RX MCS rate indexes supported: 0-7
    		HT TX MCS rate indexes are undefined
    		Bitrates (non-HT):
    			* 1.0 Mbps
    			* 2.0 Mbps (short preamble supported)
    			* 5.5 Mbps (short preamble supported)
    			* 11.0 Mbps (short preamble supported)
    			* 6.0 Mbps
    			* 9.0 Mbps
    			* 12.0 Mbps
    			* 18.0 Mbps
    			* 24.0 Mbps
    			* 36.0 Mbps
    			* 48.0 Mbps
    			* 54.0 Mbps
    		Frequencies:
    			* 2412 MHz [1] (20.0 dBm)
    			* 2417 MHz [2] (20.0 dBm)
    			* 2422 MHz [3] (20.0 dBm)
    			* 2427 MHz [4] (20.0 dBm)
    			* 2432 MHz [5] (20.0 dBm)
    			* 2437 MHz [6] (20.0 dBm)
    			* 2442 MHz [7] (20.0 dBm)
    			* 2447 MHz [8] (20.0 dBm)
    			* 2452 MHz [9] (20.0 dBm)
    			* 2457 MHz [10] (20.0 dBm)
    			* 2462 MHz [11] (20.0 dBm)
    	Band 2:
    		Capabilities: 0x1020
    			HT20
    			Static SM Power Save
    			RX HT20 SGI
    			No RX STBC
    			Max AMSDU length: 3839 bytes
    			DSSS/CCK HT40
    		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
    		Minimum RX AMPDU time spacing: 16 usec (0x07)
    		HT RX MCS rate indexes supported: 0-7
    		HT TX MCS rate indexes are undefined
    		VHT Capabilities (0x0f815832):
    			Max MPDU length: 11454
    			Supported Channel Width: neither 160 nor 80+80
    			RX LDPC
    			short GI (80 MHz)
    			SU Beamformer
    			SU Beamformee
    		VHT RX MCS set:
    			1 streams: MCS 0-9
    			2 streams: MCS 0-9
    			3 streams: not supported
    			4 streams: not supported
    			5 streams: not supported
    			6 streams: not supported
    			7 streams: not supported
    			8 streams: not supported
    		VHT RX highest supported: 0 Mbps
    		VHT TX MCS set:
    			1 streams: MCS 0-9
    			2 streams: MCS 0-9
    			3 streams: not supported
    			4 streams: not supported
    			5 streams: not supported
    			6 streams: not supported
    			7 streams: not supported
    			8 streams: not supported
    		VHT TX highest supported: 0 Mbps
    		Bitrates (non-HT):
    			* 6.0 Mbps
    			* 9.0 Mbps
    			* 12.0 Mbps
    			* 18.0 Mbps
    			* 24.0 Mbps
    			* 36.0 Mbps
    			* 48.0 Mbps
    			* 54.0 Mbps
    		Frequencies:
    			* 5180 MHz [36] (20.0 dBm)
    			* 5200 MHz [40] (20.0 dBm)
    			* 5220 MHz [44] (20.0 dBm)
    			* 5240 MHz [48] (20.0 dBm)
    			* 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
    			* 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
    			* 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
    			* 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
    			* 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
    			* 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
    			* 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
    			* 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
    			* 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
    			* 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
    			* 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
    			* 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
    			* 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
    			* 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
    			* 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
    			* 5720 MHz [144] (20.0 dBm) (no IR, radar detection)
    			* 5745 MHz [149] (20.0 dBm)
    			* 5765 MHz [153] (20.0 dBm)
    			* 5785 MHz [157] (20.0 dBm)
    			* 5805 MHz [161] (20.0 dBm)
    			* 5825 MHz [165] (20.0 dBm)
    	Supported commands:
    		 * new_interface
    		 * set_interface
    		 * new_key
    		 * start_ap
    		 * set_bss
    		 * join_ibss
    		 * set_pmksa
    		 * del_pmksa
    		 * flush_pmksa
    		 * remain_on_channel
    		 * frame
    		 * frame_wait_cancel
    		 * set_wiphy_netns
    		 * set_channel
    		 * tdls_mgmt
    		 * tdls_oper
    		 * start_p2p_device
    		 * connect
    		 * disconnect
    	Supported TX frame types:
    		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    	Supported RX frame types:
    		 * IBSS: 0xd0
    		 * managed: 0x40 0xd0
    		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * P2P-client: 0x40 0xd0
    		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
    		 * P2P-device: 0x40 0xd0
    	WoWLAN support:
    		 * wake up on anything (device continues operating normally)
    		 * wake up on pattern match, up to 8 patterns of 1-255 bytes,
    		   maximum packet offset 255 bytes
    	software interface modes (can always be added):
    	valid interface combinations:
    		 * #{ AP } <= 2, #{ managed } <= 2, #{ P2P-client, P2P-GO } <= 2, #{ P2P-device } <= 1, #{ IBSS } <= 1,
    		   total <= 4, #channels <= 2
    	Device supports scan flush.
    	Supported extended features:

     

     


  7. 2 hours ago, dolphs said:

    Wow - Would love to see my H6 and H5 boards performing with this new dev build,

    due to mainlining efforts code being merged in 5.6 as well official kernel support for wg.

     

    My auto test facility shows 1.8Ghz for Opi3 and One+, others are not hooked up due to lack of RJ45 so I don't know without looking to the code or test.

     

    IHMO for Nanopi Neo we should not change defaults. We have overlays.

     

    WG < 5.6 is maintained separately and also present in all versions of Armbian. But currently there are some problems. I believe DKMS should fix that and if not, this could be also a bug needs to be solved before 20.05. We fixed headers and sources.

     

    2 hours ago, dolphs said:

    Where is this coming from in the armbianEnv.txt OR my podgies #fingers ?

     

    Changes to scripting comes with a board support package, ex. linux-root-buster-current-orangepi3.deb

     

    5 hours ago, chwe said:

    would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there


    Do we know what will this merge drag with?


  8. 1 hour ago, trimen said:

    First and most significant is that the ethernet port isn't working properly.


    Known problem, no solution yet, but its probably some init timings. Sometimes driver fails to properly initialise the driver. 

     

    1 hour ago, trimen said:

    I connected my HD702 screen to board and if I install xubuntu-core/desktop... it works, but It's running via fb, thus it's slow and FriendlyArm OneWire touchscreen isn't working.


    I do have this screen somewhere, but was never tested. Check device tree - perhaps/probably it only needs to be enabled.

     

    1 hour ago, trimen said:

    I wasn't able to find any information if is GPU in S5P6818 supported or if it's possible to have accelerated desktop environment on it.


    We ported this work: https://github.com/rafaello7/debian-installer-nanopi-m3 More or less it works what is written there and more.


  9. 1 hour ago, Myy said:

    So Saturday 4th April on IRC then ?


    Yes, at 1 pm GMT which translates to 3 pm local time for most of EU based folks. 

     

    45 minutes ago, gprovost said:

    Would it make sense to go through each issues one by one (backlog + the ones we are supposed to fill up by the end of this week) and see if it goes or not into releases 20.05


    I leave this open for each of you. Add, change, comment, be natural and reasonable - some tasks are good, some bad, some are pointless, some need more attention, some can't be done.

     

    Also important is to fill in and close (major only) tasks that has been done after release of 20.02. since otherwise it might slip out from the release documentation. Simply open a new Jira Task or bug, add a tittle and optionally a link to forum topic or Github commit / issue / MR tag with 20.05 and set it to "Done".

     

    45 minutes ago, gprovost said:

    Then for the issue you need to figure out who he's in charge of the issue ? Hopefully someone is already in charge or you need to call someone to take charge of the issue.


    I would propose to self assign, the rest we will do in the meeting by asking people out. Anyway we usually know who is working what, but keeping track at once place is generally good and also for those that are not here every day. Assigning is not obligatory to finish the task. If you can't, speak out, perhaps someone else can take over and / or simply change its status from "In-progress" back to "To-do". https://armbian.atlassian.net/browse/AR-71

     

    45 minutes ago, gprovost said:

    Then at the end you sum-up for each contributor their list of issues they need to take care off and see if any red flag (e.g someone seems to have too many issue to resolve for its available bandwidth).


    Yes. The idea is to lower the load. I am sure sometimes we start to work on a task that is sadly too big for us and frustration kicks in. If nothing worse. This will also give us some overview what kind of help we actually need.

     

    45 minutes ago, gprovost said:

    we should be in listen mode and only interact when necessary or asked.

     

    https://github.com/armbian/documentation/commit/9ea6bcf7c77db18aeaebdfed10fce301388d1a88


  10. 6 hours ago, ning said:

    for split firmware, I can do rk3399, and amlogic. but still need other maintainer's help.


    Perhaps we need one example how this is planned and others can follow this? I am not sure everyone noticed this and even I was confused how this should be done.

     

    @sfx2000 @gprovost I would like not to deal with more gadgets at this point. We added Jira several months ago and we haven't manage to use much of its powers. IRC is nothing fancy, but its good enough. We have a channel recorder, no need to deal with any subscriptions and/or legal stuff. It works. Consider that many folks are old school or geeky, where IRC is the thing and already a Skype represent a far end of comm tools ;) 

    Anyway, my concerns goes to the meeting content. To come up with an agenda that will help us bring up, put attention to common problems and to spark our comm channel regardless of technology behind this. For the future, if majority decide we need to upgrade to something from this century :D, I will follow.


  11. 3 hours ago, Peter P said:

    I didn't find any related error message in the logs.

     

    Please let me know if you have some idea debugging this issue.

     

    Below Linux kernel 5.5.y is a legacy out of the tree version, this: https://git.zx2c4.com/wireguard-linux-compat Starting from 5.6.y WG is a part of the mainline kernel. Reports those errors / problems directly to WG authors and when they fix this, apt update and upgrade will solve it ...


  12. I ran it now on Odroid N2 and it gets stuck at:
     

    Spoiler
    
    * Removing existing Mayan EDMS and PostgreSQL containers (no data will be lost)...Done
    * Pulling (downloading) the Redis Docker image...Done
    * Pulling (downloading) the PostgreSQL Docker image...Done
    * Pulling (downloading) the Mayan EDMS Docker image...Done
    * Creating Docker network...3c6535021ac718bc12ad9d9354b446527d96ae0fec7c8911f7229c3f1ef931eb
    Done
    * Deploying the PostgreSQL container...Done
    * Deploying the Redis container...Done
    * Waiting for the PostgreSQL container to be ready (10 seconds)...Done
    * Deploying Mayan EDMS container...Done
    * Waiting for the Mayan EDMS container to be ready (might take a few minutes).............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

     


    I will ofc not proceed with debugging this 3rd party software, but it would be good to notify the author that there is something wrong ...

     

    Armbian config script only calls their installer after installing Docker first: https://github.com/armbian/config/blob/master/debian-software#L1780


  13. Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.

     

    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft

    @JMCC @Werner @karabek @martinayotte @tkaiser @selfbg ... to name just a few which might find this move useful :) 

     

    I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.


    As my example -  what I am currently working and IMHO could be implemented by 20.05:

     

    - setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.

    - merging mainstream kernel config in the non-hardware areas could go into this release

    - firmware split up with @ning

     

    ... more Jira's during a week.

     

    Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.

     

    Welcome!


  14. 20 hours ago, vlad59 said:

    u-boot stayed with 20.02.5 and not 20.02.7 with label 2019.10


    That's OK. Kernel is updated more often. 

     

    6 hours ago, president_ltd said:

    I have the same issue. LeMaker Banana Pi, has been running fine with older Raspbian image. Needed to update it for a few reasons, but SATA not recognized:


    Now this means we have a problem which needs attention.