zador.blood.stained

Super moderator
  • Content count

    3530
  • Joined

  • Last visited


Reputation Activity

  1. Like
    zador.blood.stained got a reaction from arronar in [SOLVED] openvpn - Cannot load CA certificate file ca.crt (no entries were read)   
    Possibly your CA certificate is malformed or invalid.
    The file size looks too large for a usual CA certificate. Please try to open it in a text editor and check if it looks like this
    -----BEGIN CERTIFICATE----- <several lines of characters> -----END CERTIFICATE----- or try to verify it with openssl
    openssl verify -CAfile /etc/openvpn/client/ca.crt /etc/openvpn/client/ca.crt  
  2. Like
    zador.blood.stained got a reaction from YaR in [OPi Plus 2] SPI1 pins   
    In theory - yes, but keep in mind that the bus bandwidth will be split between 3 devices so you'll get lower FPS and worse touch screen responsiveness than if they were connected to dedicated SPI controllers.
    You will need to add extra GPIO chip selects using this as an example and add 3 slave SPIdev devices like here.
  3. Like
    zador.blood.stained got a reaction from chwe in Underclock Orange Pi Zero on mainline 4.14 kernel?   
    They were always hardcoded, it's just that the sunxi legacy kernel has some hacks and closed source blobs that allow reconfiguring the DRAM frequency on the fly.
     
    "Should" is subjective here. Since nobody tried to implement this yet you can assume that developers think that this is not necessary or can't be reliably or cleanly implemented.
  4. Like
    zador.blood.stained got a reaction from chwe in BananaPi R2 (.csc)   
    You may want to play with the u-boot environment - particularly with the fdt_high value. Check the README in the u-boot sources for details.
  5. Like
    zador.blood.stained reacted to chwe in BananaPi R2 (.csc)   
    Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).
     

    (I don't found a actual picture of my revision of the board, the battery connector was removed and the powerconnectors for SATA are 5V only, so 12V rails are there but connectors on it are only GND and 5V - I probably make a picture of my board to replace this one)
     
    Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description ):
    MT7623n (ARM Cortex-A7 quad core) GbE over MTK7530 (1x "wan" 4x "lan") 2x USB 3.0 and 1 USB 2.0 otg port 2x SATA over asm1061 (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested) Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript) wifi/bluetooth combo-chip (b/g/n / 4.1) HDMI Powering over 12V barrel jack  
    Pros:
    relatively cheap (~90$ Aliexpress) Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment) 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it) MT7623 gets relatively good upstream support by Mediatek in mainline There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing ). It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds.   
    Cons:
    u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working). There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker ) http://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&amp;media=bpi-r2:boot-structure.png  the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time) During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot) There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work ), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't...   The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know. From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'. I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images.  Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.  
    So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):
    Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking) SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run). Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list').  dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse). Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot).  
    Disclaimer: 
    If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 
     
    It's not armbian, it's just a Image created with armbians buildscript at the moment:  
     
     
    This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen`  open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).
     
    So happy discussion (with valid arguments)... 
  6. Like
    zador.blood.stained got a reaction from gounthar in banana pi single boards   
    Why should we?
     
    To you? Maybe. To others? Maybe not. Especially for people who may need to do development and not just use images already made by others.
     
    And why should we work on improving that?
     
    But why don't you try this also?
     
     
    Since we received more support requests than actual board bring up threads I'm locking the "Board Bring Up" subforum. If somebody posts a proper bring up worthy thread any moderator or developer should be able to move the thread there.
  7. Like
    zador.blood.stained got a reaction from Tido in ASUS Tinker Board Bluetooth   
    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/rk3288.dtsi?id=4e943a890cef42e90f43ce6be64728a290b97c55
     
    We are talking about mainline (next branch), right?
  8. Like
    zador.blood.stained got a reaction from chwe in Underclock Orange Pi Zero on mainline 4.14 kernel?   
    They were always hardcoded, it's just that the sunxi legacy kernel has some hacks and closed source blobs that allow reconfiguring the DRAM frequency on the fly.
     
    "Should" is subjective here. Since nobody tried to implement this yet you can assume that developers think that this is not necessary or can't be reliably or cleanly implemented.
  9. Like
    zador.blood.stained got a reaction from tkaiser in zram vs swap   
    Because zram-config package exists only in Ubuntu by default, and for reasons I don't remember (probably version numbering / potential repository priority issues?) we decided to not copy it to our repository to be available for all releases.
     
    It's not set up for multi-user scenario yet (VM guests for different tasks and users instead of one shared space otherwise manual build tasks may conflict with automated ones)
     
    I meant this specific thread: https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/
    Recent examples to add to that - there is no purpose in recently added "development" branch if "master" is completely abandoned as a result and suggesting to "switch to beta" to fix any issues defeats the purpose of "beta" - fixes should be immediately pushed to the stable branch and beta should be left for non-production ready stuff.
     
  10. Like
    zador.blood.stained got a reaction from nachoparker in [Rock64 debian] Building a replica of current testing image   
    No, even if we tag the build script we are almost always using branches and not tags for upstream sources (kernel, u-boot, ATF), so it is possible that things would get changed and broken over time.
     
     LIB_TAG should be changed in the configuration file, it cannot be set via command line.
  11. Like
    zador.blood.stained got a reaction from NicoD in Which SBC should I buy next? NanoPC T3+?   
    And also https://linux-sunxi.org/Linux_mainlining_effort for the A83T mainlining status and progress (we are not touching the BSP for this SoC).
     
  12. Like
    zador.blood.stained got a reaction from Tido in board support - general discussion / project aims   
    Or it could be pushed into a separate branch, stay there while it needs testing, and then squashed into one commit and merged to master. While master is currently set to protected so it is not possible to change existing commits,  commits in other branches may be rebased, squashed or amended if necessary.
     
    We could still create temporary topic branches on demand (i.e. sunxi-next-4.17) for large change sets.
  13. Like
    zador.blood.stained got a reaction from willmore in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Then it should be called "DFS" instead 
    And yes, frequency switching should work on those images, as I remember the main problem was with the regulators (the "V" part in DVFS), and since AW refuse to provide the ARISC firmware sources it was never fixed.
  14. Like
    zador.blood.stained reacted to tkaiser in Preparing for Ubuntu 18.04   
    I would prefer to do it correctly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768
     
    And IMO there's no need to hurry and I honestly do not understand the bunch of hacks recently added to get 18.04 built now...
  15. Like
    zador.blood.stained got a reaction from JMCC in S905/X/W/D video acceleration/GPU hw + multi core processing support   
    I believe there is a simple command line player (c2play) that makes use of the VPU (similar to omxplayer on RPIs). Of course this does not integrate with FFmpeg/gstreamer and other applications that may want to use HW video decoding.
    These libraries can be used to integrate with different apps like Kodi.
  16. Like
    zador.blood.stained got a reaction from Tido in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Well, if Xunlong didn't change any markings on the board (especially the revision number) then it gets pretty nasty
     
    Compile the list of affected devices first (i.e. by contacting Steven), then put the notice regarding possible instability for newer boards on board download pages. After that there are different ways to limit the top CPU frequency, but there are multiple things to check and change - default in-kernel governor, OPPs in FEX and DT, /etc/default/cpufrequtils
  17. Like
    zador.blood.stained reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-)  The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc.  (I wish it had 1GB of RAM but that's a different subject.)  I'd love to use these boards for a number of projects.
     
    As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board.  I also enabled the allowed clock changes to 1.2GHz for cpufreq.  All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v.
     
    I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v.  I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board!  I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board.
     
    So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board.  And now it works great!  VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems.
     
    Would anyone have an idea why Xunlong doesn't solder this part on the board by default?  They include all the other parts in this part of the power circuit, just not this MOSFET.  I was going to buy a few more of these boards, and I'd like to be able to clock them up.  Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...?
     
    Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis?  My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS).  By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds.
     
    Thank you!
     
  18. Like
  19. Like
    zador.blood.stained got a reaction from MickMake in The mmBoard   
    It's much easier to make some "reference pictures" using this kind of board as a base than an SBC board.
  20. Like
    zador.blood.stained got a reaction from lanefu in The mmBoard   
    Still not nearly as impressive as the new GPU solutions for Pine64, for people who don't like the Mali 400:


     


  21. Like
    zador.blood.stained got a reaction from lanefu in The mmBoard   
    Still not nearly as impressive as the new GPU solutions for Pine64, for people who don't like the Mali 400:


     


  22. Like
    zador.blood.stained got a reaction from Dolf Andringa in Best way to contribute additional software version   
    Yes, put
    /bin/bash into your customize-image.sh to launch a shell from the customization script, do what you want and then exit the shell to continue the build process. Don't forget to kill any running services or background processes if you start any otherwise you may get unexpected issues later.
     
    It uses qemu-user emulation to execute binaries for the different architecture.
     
    This is responsible for building additional packages, outside the normal image creation process.
  23. Like
    zador.blood.stained got a reaction from Dolf Andringa in Best way to contribute additional software version   
    Yes, put
    /bin/bash into your customize-image.sh to launch a shell from the customization script, do what you want and then exit the shell to continue the build process. Don't forget to kill any running services or background processes if you start any otherwise you may get unexpected issues later.
     
    It uses qemu-user emulation to execute binaries for the different architecture.
     
    This is responsible for building additional packages, outside the normal image creation process.
  24. Like
    zador.blood.stained got a reaction from Tido in Learning from DietPi!   
    I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.
  25. Like
    zador.blood.stained got a reaction from Tido in Learning from DietPi!   
    I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.