chwe

Moderators
  • Content Count

    954
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chwe got a reaction from lanefu in Initial easy setup proposal   
    An idea which came up during coffee when I read through our documentation (I'll update it partly).. Why not implement an 'unbricker' as well?  
    http://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system
    e.g. check which one is installed and then give the user the opportunity to choose an older one. 
     
  2. Like
    chwe got a reaction from Bahaa in Armbian 5.59 and later WiFi issue   
    @botfap made an initial push to restructure network configuration prior to first boot. I didn't test it on my own yet but I assume the wifi part should work and perfectly fit for your needs.
    https://github.com/botfap/armbian-image-config
    quite sure he's happy to get some response from people actually used it.  You might give it a try? 
  3. Like
    chwe got a reaction from Igor_K in La Frite (AML-S805X-AC)   
    smart!   the connector the user normally only touches once (HDMI, Network, Powering) is on the back-side and connectors which are touched more often (USB) are on the front (assuming IR is normally on the front side). A bit risky but IMO interesting is to throw out the microSD slot. It may solve a bunch of those support questions which end normally here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ (at least the SD related ones ) and 12MB SPI flash is more than enough.  IMO an important 'what if' question:
    What if I mess up the bootloader and brick it? I'm not familiar with enough with Amlogic SoCs, are they 'failsave' to unbrick SPI once it's messed up (e.g. something like RKs recovery tools?). I've a talent in messing up u-boot, luckily this only happened on SD-card (of fail-save sunxi) yet, where it wasn't much an issue. I probably pledge for a 1gb version if there are still some left for 19$ when I'm back at home..  Not that I'm interested in Kodi on Linux stuff, still a mystery to me why people want Kodi on Linux (anyway, I don't need to understand everything)..  But I appreciate your contribution towards mainline support for hardware accelerated video en/decoding and it could be a cute little IoT end-node for systems where you can't trust that your device doesn't magically disappears (others would call it someone steals your stuff). At least potential confidential information of this node is not in the wrong hands as soon as they cut power. A cute little toy to get a feeling for PXE related stuff. 
  4. Like
    chwe reacted to JMCC in [HOWTO]: Emby Server with hardware transcoding in XU4/HC1/HC2 Armbian Stretch   
    As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
     
    Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
     
    However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
     
    So this is a step-by step guide on how to make everything work:
     
    0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
     
    >> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install   
    Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
    Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
    Restart the service:
    $ sudo service emby-server restart  
    Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
    For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
     
     

     
    And that's it!
     
    As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
     
    Enjoy! And please, share your experiences and comments here.
  5. Like
    chwe got a reaction from Igor_K in La Frite (AML-S805X-AC)   
    smart!   the connector the user normally only touches once (HDMI, Network, Powering) is on the back-side and connectors which are touched more often (USB) are on the front (assuming IR is normally on the front side). A bit risky but IMO interesting is to throw out the microSD slot. It may solve a bunch of those support questions which end normally here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ (at least the SD related ones ) and 12MB SPI flash is more than enough.  IMO an important 'what if' question:
    What if I mess up the bootloader and brick it? I'm not familiar with enough with Amlogic SoCs, are they 'failsave' to unbrick SPI once it's messed up (e.g. something like RKs recovery tools?). I've a talent in messing up u-boot, luckily this only happened on SD-card (of fail-save sunxi) yet, where it wasn't much an issue. I probably pledge for a 1gb version if there are still some left for 19$ when I'm back at home..  Not that I'm interested in Kodi on Linux stuff, still a mystery to me why people want Kodi on Linux (anyway, I don't need to understand everything)..  But I appreciate your contribution towards mainline support for hardware accelerated video en/decoding and it could be a cute little IoT end-node for systems where you can't trust that your device doesn't magically disappears (others would call it someone steals your stuff). At least potential confidential information of this node is not in the wrong hands as soon as they cut power. A cute little toy to get a feeling for PXE related stuff. 
  6. Like
    chwe reacted to NicoD in USB-C powered boards -- important information   
    The problem was my cable. I'm sorry for the confusion.
    I've tried again with the short cable they gave with it, and it's a lot better. 1A load and cpu maxed in Armbian makes it sink 0.4V instead of 1V. A huge difference. I should have seen it earlier. The cable was too short to put the M4 on my table with it...
    Sorry. Only issue is that it reached 85°C without a fan. But that's only after +14minutes full load. People who max these things should know to use a fan.
    Cheers
     
  7. Like
    chwe got a reaction from DBB in sysfs thermal and cpufreq info on the orange pi zero   
    /dts-v1/; #include "sun8i-h3.dtsi" #include "sunxi-common-regulators.dtsi"
  8. Like
    chwe got a reaction from SKD in SD card Clone not working in new banana pi zero   
    I still don't get what you want to achieve.. 
    You've two of those right?

    and you want to clone an image prepared for one for the other?
     
    likely that you're not superuser (e.g. sudo ifconfig)
     
    I assume you use an image provided from here? http://forum.banana-pi.org/t/topic/5485
    In this case I would ask the guy who provides those images what's going wrong. I've no idea what his default configuration is and how those images are built. 
    We only provide the build option as CSC (community supported configuration) which means, no end-user support and not tested. In case such an Image refuses to boot or doesn't work as expected community members have to nail down the problems and send patches to armbian to fix it the core member wont fix it. For Images provided not on dl.armbian.com or armbian.com --> downloads, we can't give any end-user support cause we've no clue who made them and if they're made in a sane fashion. 
    If it is made properly, network configuration should be possible over NetworkManager see:
    http://docs.armbian.com/User-Guide_Getting-Started/#how-to-connect-to-wireless
    Ethernet (over a soldered RJ45 according to this) was never tested cause the rework of the patches which should fix the board for proper boot were done by myself (https://github.com/armbian/build/pull/957) and back then, I only tested what's actually populated on the board (wifi) plus serial console over the 3-pin header next to HDMI. 
     
    the naming is confusing here:
    but it doesn't matter we don't provide a 5.41 image for both. (M2 got eos with 5.38) and the only 'Armbian' images for the BPi-M2-Zero were provided on Sinovoips forum and not on our dl page. Due to messed up CS pins in I'm quite confident that most images which don't disable CS (the BPi way - which was potentially harmful for the rest of our boards, that's why we don't have it in our repo) or having this patch https://github.com/armbian/build/blob/bf5a2fe6e02c3360bd94d45978f4c51135558f61/patch/u-boot/u-boot-sunxi/add-bananapi-bpi-zero.patch#L184 (which in fact disables CS in the first stage as well before DT kicks in) will simply refuse to boot. 
     
    So IMO you've two options:
    build an Image on your own with our buildscript and the patches we provide use the image provided by BPi and ask in their forum for support For option 1 I may give you some advice cause I was the original submitter of those patches (even when we don't support it) - for issues related to soldered RJ45 on the 4pin header I'm not willing to give you advice, I assume it won't work on 4.14 kernel (next) or 4.18 (dev) cause the emac nodes are missing in DT, I've no idea if it works on 3.4.113 kernel cause I don't deal with fex files anymore. For option 2 it's IMO a simple 'not our business' issue. I'm not willing to nail down problems on images made by someone else where I've no idea what patches were applied. 
  9. Like
    chwe got a reaction from NicoD in USB-C powered boards -- important information   
    well, there you go: http://docs.armbian.com/Process_Contribute/ 
    The way this might be possible is over devicetree overlay. Someone has to implement it, someone has to test it and to quote @Igor: Those 'someones' are rare and the few we have are already overloaded. You may want to make a video how you improved armbian by patching not only reporting?  
    Maybe you can simply adjust it similar to here?
     
    I never tested it on big.LITTLE SoCs 
  10. Like
    chwe reacted to Igor in Access Point Ralink MT7601U (148f:7601) Wi-Fi on Ubuntu Bionic   
    https://github.com/armbian/documentation/commit/c6cfb75f75fa4f096eab5282dee06ad8ad518412
    apt update and upgrade and its done.
  11. Like
    chwe got a reaction from Werner in (not so) Stupid question - save bandwidth in cleanlevel   
    Do it as you think it's best and if it turns out that it isn't perfect, the PR can still be edited before it gets merged. I would link to those two threads when sending the PR, so that a reviewer know where it comes from.  
  12. Like
    chwe got a reaction from sfx2000 in Daily (tech related) news diet   
    well, here's some PR stuff how people think a lab should look like..

    better?  But, we don't use plastic molecule models in our lab.. Acetone for cleaning will likely f*ck them up (a bunch of plastics get dissolved by acetone, and acetone is common to clean stuff in the lab).. 
     
    We don't dissolve potassium permanganate that often to get those nice purple solutions (we do it.. but then to oxidize TLC plates).. Or Copper sulfate for the blue one, or basic phenolphthalein for pink and methyl orange for the orange one..  That's not how chemistry looks like..  Your products are mostly brown, or yellow, or ocher, or tones of those colors before purification.. sticky brown residue describes the product often best..  Such nice looking crystals 

    is something you only grow if you do x-ray for structure determination and you didn't run out of budget (x-ray is done by other experts, and they're expensive and the whole process is time consuming).. 
    The fume hood I showed isn't a perfect one, and I would change several things, but it's a realistic one. I saw a bunch of worse fume hoods during my career.. 
    There are even people proudly show their mess on reddit.. 
    Have fun to explain your insurance company that this is an appropriate work place if you burn something down.. If you didn't have time to clean your mess partly during a 14h prep session, you did IMO something wrong.. But well, chemists tend to be messy..  
     
     
  13. Like
    chwe got a reaction from Bahaa in Armbian 5.59 and later WiFi issue   
    http://docs.armbian.com/User-Guide_Getting-Started/#how-to-connect-to-wireless
    per default, wifi is handled by NetworkManager. It may overwrite your credentials which then messes up.
  14. Like
    chwe reacted to getreu in Crypto kernel modules missing for aes-xts-plain64 cipher   
    >   I assume chances are hight that the new kernelconfig will be merged into Armbian and everyone can benefit from your work
     
    I pushed this pull request:   https://github.com/armbian/build/pull/1123
     
    >    There is still one problem remaining: OpenMediaVault 4 does not recognize `/dev/mapper/dm-name-md1-crypt` as a device.

    The problem solved itself! No idea how and why. Maybe it needed just a reboot.
  15. Like
    chwe got a reaction from lanefu in board support - general discussion / project aims   
    Background: the last 7 posts came from:
     
    I think those discussions fit better here than elsewere...  Some updates for the table:
     
    not 100% properly updated - feel free to enhance.  
  16. Like
    chwe reacted to TonyMac32 in Pi-factor cases   
    It doesn't power via USB-C, so should not be an issue.
  17. Like
    chwe got a reaction from Ryder.Lee in BananaPi R2 (.csc mt7623 as new boardfamily)   
    u-boot had to learn bootz and ext commands first.  
    diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig index 642dc9f..ce30e40 100644 --- a/configs/mt7623n_bpir2_defconfig +++ b/configs/mt7623n_bpir2_defconfig @@ -13,6 +13,7 @@ CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_BOOTZ=y CONFIG_CMD_BOOTMENU=y # CONFIG_CMD_ELF is not set # CONFIG_CMD_XIMG is not set @@ -25,6 +26,8 @@ CONFIG_CMD_READ=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set CONFIG_CMD_PING=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y but that's because armbian doesn't use fat for kernel and zImages instead of uImages.. 
    Far away from 'automated' but yes boot up isn't much an issue:
    was just a quick and dirty test..  
     
    you can test it on https://github.com/chwe17/build/tree/mt7623 only dev kernel currently tested (btw. the gmac2 patch should be removed it never worked as expected), next is probably broken at the moment.. 
  18. Like
    chwe reacted to Ryder.Lee in BananaPi R2 (.csc mt7623 as new boardfamily)   
    Hello,
     
    Add latest U-boot support for MT7623 SoC
     
    Status:
    I’ve already sent the first round patches for MT7623n,  and the most of the drivers are based on mainline Linux, like clock, timer, mmc, pinctrl, watchdog, power domain and DTS.
     
    The following are the major differences between Linux and U-boot:
    -modify the driver interface to adapt the U-boot DM framework.
    -remove unneeded DT nodes as they don’t have proper drivers in U-boot yet.
    -just add the basic functions (step-by-step) so that we can monitor the size.
    -reuse ns16550.c but add a highspeed register for MediaTek UARTs.
     
    The current progress:
    -Boot from eMMC or SD card.
    -ROM -> MediaTek preloder -> U-boot -> Linux
     
    TODO:
    -Ethernet
     
    The patch sets:
    -https://patchwork.ozlabs.org/project/uboot/list/?series=68601
     
    How to build:
    -make mt7623n_bpir2_defconfig; make
     
    Ryder
  19. Like
    chwe got a reaction from gounthar in USB-C powered boards -- important information   
    Some SBCs for which Armbian images are available (supported, wip or csc) can be powered via USB-C. Depending on its implementation, some pitfalls must be considered. This short tutorial should give you an overview. 
     
    'Dumb mode':
    The USB-C connector is used similar to the microUSB connectors in previous SBCs. Means that the pitfalls must be considered when you choose a charger and cable. See the following thread for some background:
    Additionally, those boards may be problematic with PD compatible chargers. Without a proper PD implementation those PSUs will only deliver up to 900mA at 5V (4.5W). In case you have a board which isn't PD compliant you should go for a PSU without PD implementation aka 'dumb PSU'. Voltage drop from cable and voltage drop of the PSU at hight load itself must be kept in mind similar to microUSB powered boards!
    SBCs which don't support PD (also boards not supported in any form by Armbian):
    Vim Vim2 NanoPi M4 NanoPi NEO4  
    PD mode (power detection):
    With a proper PD implementation, a PD capable PSU can deliver 'more juice' on demand. It's also possible to deliver power at higher voltage (between 5V and 20V). See graphic (12V is missing here):

    (source: https://www.digikey.ch/en/articles/techzone/2017/mar/designing-in-usb-type-c-and-using-power-delivery-for-rapid-charging)
    To ensure proper powering you should go for a PD compliant PSU. See documentation of your board to see which PD modes are supported within your SBC. Boards known to support PD-Mode:
    ROC-RK3399-PC (Renegade Elite)
     
  20. Like
    chwe got a reaction from gounthar in What would you choose to record and broadcast video?   
    not really. The tinker can work with RPi cameras e.g. OV5647 and IMX219 as long they've the same pinout (sold as 'RPi compatible') but the kernel must be fixed first.. go through:
    and
     
    firefly compatibles (not my field cause I don't own it and never spent much attention to it) but there was someone who digged into the OV13850 during ISP1 development:
    https://github.com/rockchip-linux/kernel/issues/33
    https://github.com/rockchip-linux/kernel/issues/112
    https://www.bountysource.com/issues/48831243-rockchip-isp1-driver
     
    I had in mind that they got it finally working but no idea where that post is... 
     
    I assume this one as compatible.. but that's up to you to clarify it before you buy one..  
    https://www.amazon.com/OV13850-Camera-Module-Firefly-RK3288-Optional/dp/B06XBMNH77
     
    For the tinker:
    https://github.com/chwe17/build/blob/rockchip-default/config/kernel/linux-rockchip-default.config back then 'worked' but for sure the patch series and a bunch of other stuff will be broken now.. go through:
    https://github.com/chwe17/build/commit/c26f02b65e6ac1c697b48d7677d1f178017f3994 to get an idea... I somehow lost the interest back then.. 
  21. Like
    chwe reacted to going in (not so) Stupid question - save bandwidth in cleanlevel   
    For me, these three points are a big problem.
    If the founding fathers and users feel similar, I can provide a patch that fixes these issues.
  22. Like
    chwe got a reaction from gounthar in What would you choose to record and broadcast video?   
    The only board with a RPi 'compatible' CSI is to my knowledge the tinker... Some RK3399 boards do also have CSI ports but I'm not sure if they've the same pin-out (had in mind that they've mostly a 'firefly' compatible which differs from the 'rpi' compatible). Just check it properly before you choose one.  
  23. Like
    chwe reacted to tkaiser in NanoPi Neo 2: GbE works in 4.14.y Armbian?   
    Count the patches and search for NEO2 there: https://github.com/armbian/build/tree/master/patch/kernel/sunxi-next
  24. Like
    chwe reacted to TonyMac32 in board support - general discussion / project aims   
    There isn't a waiting list on bus accidents I hope?? 
     
    We don't use busses, every American has a 4WD V8 truck with giant tires and American flags flying in the bed.  :lol:.  I could get hit by one of those...
     
     
  25. Like
    chwe got a reaction from Christian_ in HDMI-Monitor bricked tinkers today (next 5.60)   
    or... you SSH into a working SBC and use it's spare UART pins to ttl into the non-working SBC... 
    Likely to be one of the most silly things I've ever did with an SBC.. But hey, it works...  (at least @martinayotte will like it.   )
     

     

     
     
    do we have UART2 and UART3? at least on mine (4.14) we use UART3...  @TonyMac32? Or was it back then when we used UART2? Can't remember anymore..