Jump to content

Igor

Administrators
  • Posts

    13589
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Igor got a reaction from manuti in Changing to Chromium   
    Firefox 54 finally goes multi-process, eight years after work began
    https://arstechnica.co.uk/information-technology/2017/06/firefox-multiple-content-processes
  2. Like
    Igor reacted to martinayotte in No network after upgrade to 5.30   
    By using picocom or putty on serial debug, and copy/paste the output ...
  3. Like
    Igor got a reaction from hrip6 in No network after upgrade to 5.30   
    I just test the upgrade once again. Starting with this image: https://dl.armbian.com/bananapi/archive/Armbian_5.25_Bananapi_Debian_jessie_next_4.9.7.7z
     
    apt update
    apt upgrade
     
    Zero problems. 
     
    Logs: http://sprunge.us/QjUT
  4. Like
    Igor got a reaction from manuti in No network after upgrade to 5.30   
    Repository just bumped to 5.31 which should fix the problem of this topic - updating. Affected images are in process of replacing.
  5. Like
    Igor got a reaction from manuti in No network after upgrade to 5.30   
    The more I test, the less I know  This test image works fine on M1+, while network doesn't come up (properly) on: M1, PRO and R1
  6. Like
    Igor got a reaction from Charizard in No network after upgrade to 5.30   
    R1 with v5.31 legacy works. 
     
    Will rebuild in the morning. 
  7. Like
    Igor got a reaction from manuti in Nightly images?   
    I support the idea of protocol - if this is meant that way - but honestly I haven't been able to catch up - only quick scan. 
     

    My impression is different. A lot has been done, but also a lot can be done. The question is, what do we want and can we afford? Some things were made wrong, but in general we don't waste that much time either (if we rule out supporting Orange Pi zero wireless, similar pointless cases and perhaps support in general). We are already at a limit of what we can do with resources we have and that is one of the primary reasons, why all things weren't done yet. Even we cut off half of the board support ...

    There is more than just clear comm and few rules to achieve greatness.

    20 tools, each covering one aspect of a community or group by Pieter Hintjens:
     

     
     
    It could have impact or not. Perhaps our way of doing is too good, strict or perfect? It depend from which perspective do we look. I know that current scenario of engagement is not ideal and needs change if we don't want to get crazy and to level things up. This takes time and energy and we are going from one large project to another without stop. I see that more problematic than we failed to implement some protocol or feature.
     

    Actually we did testings, but this kind of issue could be found only if all boards were tested. We are not on that level, even 5 people (we have 8 people in total for testing from last call, but theirs board diversity is another problem) responded to assigned tasks. Testing protocol was not fixed yet, since we need few real world experiences, before we know what is important and to wrote all this down.
     
    We need to divide stable and latest builds, freeze non critical stuff (u-boot), ... yes. 

    I'll fix recent upgrade problems, when I'll fully understand them, but first I would need to get some sleep and recharge. I removed failed u-boot from repo but images for bananas are failed too.
  8. Like
    Igor got a reaction from Tido in Nightly images?   
    @tkaiser & anyone else -> text at download pages comes from here: https://github.com/armbian/documentation/commit/10c08d02fbd67c9cf79e0e7fe8ff4d0ee2da3b9e
     
    Feel free to alter - updated auto in matter of minutes.
  9. Like
    Igor got a reaction from TheLinuxBug in Espressobin support development efforts   
    @lanefu I add few fixes since I just received my board and needed to try out a bit ...  to be continued.
  10. Like
    Igor got a reaction from lanefu in Espressobin support development efforts   
    @lanefu I add few fixes since I just received my board and needed to try out a bit ...  to be continued.
  11. Like
    Igor got a reaction from tkaiser in Espressobin support development efforts   
    @lanefu I add few fixes since I just received my board and needed to try out a bit ...  to be continued.
  12. Like
    Igor reacted to Vladimir Gamalian in Nanopi neo, internal USB seems disabled   
    Finally all the hubs work fine. The solution is:
    copy /boot/dtb-4.10.11-sun8i/overlay/sun8i-h3-usbhost0.dtbo to /boot/dtb-4.10.11-sun8i/overlay/sun8i-h3-usbhost1.dtbo change ehci0 to ehci1 and ohci0 to ohci1 in /boot/dtb-4.10.11-sun8i/overlay/sun8i-h3-usbhost1.dtbo insert to /boot/armbianEnv.txt line: overlays=usbhost0 usbhost1 usbhost2 usbhost3 reboot  
     
  13. Like
    Igor got a reaction from sufialhussaini in Mod nand-sata-install for SD with separate boot partition   
    Steps from 2015 might not work today ... btw. Why don't you use our script? It works out of the box. I think it should work also with two partitions.
  14. Like
    Igor reacted to sufialhussaini in Mod nand-sata-install for SD with separate boot partition   
    The latest `nand-sata-install.sh` scripts works great! Thanks again!
  15. Like
    Igor got a reaction from op1tjaap in Compiling a custom kernel. linux-dtb-dev...... is missing   
    If you are using our build scrpit - you already can do that - just use the packaging adjustements we made. And those you did, they look o.k. to me. Well, the kernel branch you are using, might not be bootable? Try first with some stable branch, "known to work kernel". 4.12 and sun8i doesn't look close to fully stable branch.
  16. Like
    Igor got a reaction from Tido in Nightly images?   
    When "include beta and deprecated images" is checked, Why is my board not supported? link pop's out and that will be relinked to github or rendered here: https://www.armbian.com/unsupported/
     
    That's really all for today. Have to do some barbecue
  17. Like
    Igor got a reaction from Tido in Nightly images?   
    What about just removing unsupported board(s) from forum description & closing new topics with "no more active support"? I don't expect much if any activity on those boards.
     
    If no objections pops out, those four will get last update with 5.30 and will be moved our from armbian mainline support.
  18. Like
    Igor got a reaction from tkaiser in Nightly images?   
    My proposal for removal:

    https://www.armbian.com/orange-pi-mini/ (limited edition, no samples, never sold)
    https://www.armbian.com/orange-pi/ (limited edition, no samples, never sold)
    https://www.armbian.com/lemaker-guitar/ (no development for some time, design flaws, no mainline)
    https://www.armbian.com/roseapple-pi/ (no development for some time, design flaws, no mainline, never sold)
  19. Like
    Igor got a reaction from tkaiser in Clearfog base: temperature / alternative heatsink recommendations   
    IIRC it's a leftover from first kernel, which had wrong readings. I'll check and adjust values ... 
  20. Like
    Igor got a reaction from manuti in Nightly images?   
    My proposal for removal:

    https://www.armbian.com/orange-pi-mini/ (limited edition, no samples, never sold)
    https://www.armbian.com/orange-pi/ (limited edition, no samples, never sold)
    https://www.armbian.com/lemaker-guitar/ (no development for some time, design flaws, no mainline)
    https://www.armbian.com/roseapple-pi/ (no development for some time, design flaws, no mainline, never sold)
  21. Like
    Igor reacted to jethro in Docker on H3 Armbian   
    Great -I think I get it now. Thanks again!
  22. Like
    Igor got a reaction from jethro in Docker on H3 Armbian   
    - default means old legacy kernel. Pretty much works, but ofc no docker support since kernel is too old.
    - nightly indicates automated builds with whatever kernel
    - we usually don't provide "DEV" images. Usually they are in nightly builds or you can made them manually
    - in build higher than 5.27 (current betas) is it possible to switch kernels from armbian-config menu. So you don't need to worry about ... 
    - default will stay default for ever or at least for some time. DEV will become NEXT which indicates "Next kernel generation"
  23. Like
    Igor got a reaction from lafalken in RK3328 Kernel   
    Our root system is simple to maintain, matured, clean - in any way better than official creations. I am not sure anyone wants to analyse, how Asus glue their images together. They failed on board design and generally all board makers images proved to be bad quality. We only peek for some special thing, but here I don't see any reason.
     
    We just started to add wireless and Bluetooth support and I am not sure it's already fully done. ASUS still haven't deliver board samples, which means not many people can work on this.
     

    You have to contact image creators (Asus or whoever). There is a reason why we don't alter stock Debian / Ubuntu much, since there is plenty of complexity already and time is wasted on irrelevant issues.
  24. Like
    Igor got a reaction from berkovsky in nand-sata-install script   
    This is not a problem but dirty "NAND availability check" ... BTW: for armbian-config testing you only need to switch to beta repository and issue apt-get update / upgrade.
  25. Like
    Igor reacted to Sauron in [SOLVED] Banana Pi playing 24/192 as 24/96 using ALSA+MPD   
    I recently switched from a Raspberry Pi 2 running Arch Linux to a Banana Pi (the original) running Armbian for music streaming using MPD. My output device is an XMOS-based Gustard U12 asynchronous USB transport feeding my DAC via AES/EBU.
    Using Armbian on the Banana Pi, all my 24-bit/192kHz music is being played back as 24/96, according to the display on the transport and DAC. All other sample rates (44.1, 88.2 etc.) are being played back in their native sample rates, as expected.
     
    Is ALSA on Armbian system-wide limited to 96 kHz?
    I have never had an issue like this before, and I don't know where to begin in regards to troubleshooting. I'm guessing that the audio is being passed through dmix, but I don't understand why it only happens to 24/192 content.
     
    The Banana Pi is using kernel 4.9.12, whereas my Raspberry Pi with Arch is using version 4.9.27.
     
    I'm using the following in my mpd.conf:
    audio_output {     type         "alsa"     name        "Gustard U12"     device       "hw:1,0"     mixer_type  "software"     auto_resample "no"     auto_channels "no"     auto_format "no"     use_mmap     "yes" } I have also tried use_mmap "no", to no avail.
     
    EDIT:
    According to /proc/asound, it seems like the ALSA device is limited to 96kHz:
    $ cat /proc/asound/card1/stream0 XMOS xCORE USB Audio 2.0 at usb-1c1c400.usb-1, full speed : USB Audio Playback: Status: Running Interface = 1 Altset = 2 Packet Size = 224 Momentary freq = 44096 Hz (0x2c.1880) Feedback Format = 18.14 Interface 1 Altset 1 Format: S24_3LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000 Interface 1 Altset 2 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000 Interface 1 Altset 3 Format: SPECIAL DSD_U32_BE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000 But how can that be, when it works just fine on a different distro? Could it be the USB port falling back to USB 1.1 speeds for some reason? Can I check that somehow?
     
    EDIT²:
    Okay, my USB 1.x theory turned out to be correct - the cable was the culprit. When switching to the Banana Pi, I also switched to a shorter cable which apparently was an ancient USB 1.x cable. After replugging the old cable, everything is fine and 192kHz works as expected. Now the proc output also says "high speed" instead of "full speed":
    $ cat /proc/asound/card1/stream0 XMOS xCORE USB Audio 2.0 at usb-1c1c000.usb-1, high speed : USB Audio Playback: Status: Running Interface = 1 Altset = 2 Packet Size = 28 Momentary freq = 44097 Hz (0x5.8318) Feedback Format = 16.16 Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000 Data packet interval: 125 us Interface 1 Altset 2 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000 Data packet interval: 125 us Interface 1 Altset 3 Format: SPECIAL DSD_U32_BE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000 Data packet interval: 125 us  
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines