zador.blood.stained

Super moderator
  • Content Count

    3633
  • Joined

  • Last visited


Reputation Activity

  1. Like
    zador.blood.stained got a reaction from Oleksii in NanoPC T4   
    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  2. Like
    zador.blood.stained got a reaction from Tido in Improve 'Support over Forum' situation   
    I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?
  3. Like
    zador.blood.stained got a reaction from gas_85 in Can't use Openvpn cause of missing /dev/net/tun   
    sudo modprobe tun If this fixes the error for you, you should add
    tun to /etc/modules (on a new line)
  4. Like
    zador.blood.stained got a reaction from NicoD in Just a test   
    First I would change and reword the current implementation - use something like "I understand that not providing requested information will reduce the chance to solve my issue" (current one with the possibility of getting banned doesn't correlate with the forum rules), explain why providing armbianmonitor -u info is needed (I checked a few new new threads and they don't have it), deal with old images that try to upload the info to sprunge.us (i.e. by linking an instructions for updating the script without updating the BSP), ideally deal with the possibility that ix.io may stop to provide its free service one day too, etc.
    I'll just leave the public download statistics link here. I'm not an expert on hosting prices in EU, but you need to take into account both the storage space and monthly traffic.
    Edit: clarification - this is daily stats that don't include torrent traffic.
  5. Like
    zador.blood.stained got a reaction from martinayotte in Just a test   
    Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
     
    For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
     
    Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
     
    Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
    Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
    Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.
  6. Like
    zador.blood.stained got a reaction from Tido in Just a test   
    Don't get me wrong, I'm not a fan of the current form implementation, but it's only the first iteration. Since "Technical support" section is mostly used as a bug tracker and we wouldn't be able to support a standalone bug tracker / task management system, adding data collection form to the forum is a step in the right direction.
  7. Like
    zador.blood.stained got a reaction from Tido in Just a test   
    Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
     
    For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
     
    Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
     
    Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
    Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
    Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.
  8. Like
    zador.blood.stained got a reaction from NicoD in Just a test   
    Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
     
    For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
     
    Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
     
    Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
    Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
    Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.
  9. Like
    zador.blood.stained reacted to Igor in Improve 'Support over Forum' situation   
    Plus adding this plugin
    https://invisioncommunity.com/files/file/9042-auto-lock-topics/
    to entire Technical support question with locking everything that older than 90days? 

    This would make sense in a combination with various restriction for creating a new topics (adding armbianmonitor -u).
  10. Like
    zador.blood.stained got a reaction from @lex in NanoPC T4   
    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  11. Like
    zador.blood.stained got a reaction from chwe in NanoPC T4   
    Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
  12. Like
    zador.blood.stained got a reaction from TonyMac32 in board support - general discussion / project aims   
    And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
     
    Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
     
    Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."
  13. Like
    zador.blood.stained got a reaction from Tido in board support - general discussion / project aims   
    And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
     
    Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
     
    Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."
  14. Like
    zador.blood.stained got a reaction from TonyMac32 in RK3288 device tree overlays   
    At least the vanilla mainline u-boot "fdt apply" requires OF_LIBFDT_OVERLAY (which there is set on the per board basis, but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-DT-overlays-support.patch
  15. Like
    zador.blood.stained got a reaction from Tido in board support - general discussion / project aims   
    Yes, but is it still manufactured? Is it still sold worldwide? And what will you do if you are an "interested developer" and your board dies? Buy another one (if it would be even possible) or move it to "community supported"?
    I'm not saying that we should drop support for this particular board right now (I'm sure that @tkaiser would have a different opinion) but any device will fade out in time, regardless of the history.
     
  16. Like
    zador.blood.stained got a reaction from Tido in board support - general discussion / project aims   
    Things to add IMO, some general forum rules to let moderators make decisions based on written rules instead of personal opinions (yes, I think we already discussed this more than a year ago):
     - primary forum language is English, messages in other languages without translation outside of "General chit chat" section may be hidden or deleted
    - don't bump topics too often and don't create duplicate messages and topics to bring attention to your issue
    - be respectful to each other, follow the nettiquette
    - don't abuse private messaging for tech support
    - don't abuse forum for self-promotion and don't spam
    - breaking the rules will result in a warning, getting multiple warnings will result in a ban
     
     
  17. Like
    zador.blood.stained got a reaction from TonyMac32 in board support - general discussion / project aims   
    Then the project should be scaled back to the point where it is sustainable?
     
    If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it?
     
    Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time.
     
    I think this would help too, I don't want to wash my eyes with a soap after reading some threads.
  18. Like
    zador.blood.stained got a reaction from Tido in board support - general discussion / project aims   
    Then the project should be scaled back to the point where it is sustainable?
     
    If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it?
     
    Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time.
     
    I think this would help too, I don't want to wash my eyes with a soap after reading some threads.
  19. Like
    zador.blood.stained got a reaction from Jens Bauer in Clearfog Base with eMMC first boot tutorial   
    Did you add "emmc_fix=on" to /boot/armbianEnv.txt on the eMMC (you needed to mount it after flashing) or did you try to insert a SD card in the microSD slot on the board? Without this eMMC won't be detected by the kernel.
  20. Like
    zador.blood.stained got a reaction from Jens Bauer in Clearfog Base with eMMC first boot tutorial   
    You can copy it to the same USB stick (as a file) and dd it to the eMMC. Please note that you need to add/set "emmc_fix=on" in /boot/armbianEnv.txt both on your USB stick and on eMMC after you flash the image on it, or you can just insert any SD card into the SD slot.
     
    There is no USB OTG port here so UMS (mass storage gadget) or fastboot is not an option here. The only "better" solution could be tftp based to download the image to RAM or USB storage and flash it to eMMC, but it requires setting up a tftp server, or writing the image from USB to eMMC from u-boot.
  21. Like
    zador.blood.stained got a reaction from Jens Bauer in Clearfog Base with eMMC first boot tutorial   
    OFF,OFF,ON,ON,ON as per Solid-Run wiki for SD/eMMC. 
  22. Like
    zador.blood.stained got a reaction from Jens Bauer in Clearfog Base with eMMC first boot tutorial   
    Please try setting switches to OFF,ON,OFF,OFF,ON instead.
     
    I just tried to use kwboot from mainline u-boot and it worked fine for me
    git clone --depth 1 git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- clearfog_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- tools tools/kwboot -b ~/u-boot-uart.mmc /dev/ttyUSB0 screen /dev/ttyUSB0 115200  
  23. Like
    zador.blood.stained got a reaction from Jens Bauer in Clearfog Base with eMMC first boot tutorial   
    It may be easier to unpack the .deb package from here than mounting the existing image and extracting files from its filesystem.
     
    Not with PuTTY and I'm not sure if there is a good way to do it from Windows in general.
    I would recommend reading this tutorial and official Solid-Run instructions here.
    You can get the u-boot binary from Armbian packages and this binary can easily boot an image from USB flash with "run usbboot" but you still need to find a way to load the u-boot via UART (either using kwboot or scripts linked in the first tutorial).
     
    It is.
  24. Like
    zador.blood.stained got a reaction from esbeeb in Learning from DietPi!   
    IMO "linux-firmare" in Ubuntu based images should be installed by default as it contains firmware for popular wireless and multimedia devices. Solving random firmware related problems is a complicated task for our user base.
  25. Like
    zador.blood.stained got a reaction from lanefu in why does passing KEY=value args to compile.sh work?   
    https://github.com/armbian/build/blob/master/compile.sh#L51-L59
    # Script parameters handling for i in "$@"; do if [[ $i == *=* ]]; then parameter=${i%%=*} value=${i##*=} display_alert "Command line: setting $parameter to" "${value:-(empty)}" "info" eval $parameter=$value fi done  
    Not sure if this solution is 100% bullet-proof (i.e. for handling special characters and values with spaces) but it works for the build script needs.