Jump to content

lanefu

Members
  • Posts

    1331
  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu reacted to martinayotte in Start looking at 5.3.y   
    Tested on forgotten boards in first AllWinner's garden Tour : nanopiduo2, nanopineo2, nanopim1plus2 and bananapim2plus ...
  2. Like
    lanefu reacted to guidol in Start looking at 5.3.y   
    Great Job @martinayotte !
    I did a new compile with 5.3 - and no exception anymore AND restart does work
    (also while using the NAS-Hat for the OPi Zero on the OPi R1  )
    login as: root root@192.168.6.101's password: ___ ____ _ ____ _ / _ \| _ \(_) | _ \/ | | | | | |_) | | | |_) | | | |_| | __/| | | _ <| | \___/|_| |_| |_| \_\_| Welcome to Debian Buster with Armbian Linux 5.3.0-rc3-sunxi package bsp-kernel[5.94] u-boot[5.94] dtb[5.94] firmware[5.94] config[5.94] System load: 0.72 0.26 0.09 Up time: 1 min Memory usage: 32 % of 238MB IP: 192.168.6.101 CPU temp: 46°C Usage of /: 7% of 15G Last login: Fri Aug 16 23:42:39 2019 from 192.168.6.17 root@opi-r1(192.168.6.101):~#  

  3. Like
    lanefu reacted to pavelectric in RK3399 UEFI Firmware   
    I hope this never happens. It was still not enough to put this demonic operating system on an excellent board.
  4. Like
    lanefu reacted to Igor in OctoPrint + Motion in armbian-config   
    ... has already made himself enough big pile of maintenance work. Without adding this. Certainly don't need more  But I will find time for review if you get it to the PR phase.
  5. Like
    lanefu reacted to bksoux in Helios4 Support   
    Just received and set up the Helios4! My first NAS.
    Everything's going fine for now. Drives are syncing.
     
     
     
  6. Like
    lanefu reacted to TonyMac32 in La Frite (AML-S805X-AC)   
    _ _____ _ _ | | __ _ | ___| __(_) |_ ___ | | / _` | | |_ | '__| | __/ _ \ | |__| (_| | | _|| | | | || __/ |_____\__,_| |_| |_| |_|\__\___| Welcome to Ubuntu Bionic with Armbian Linux 5.2.8-meson64 System load: 1.23 0.45 0.17 Up time: 5 min Memory usage: 11 % of 967MB IP: CPU temp: 55°C Usage of /: 4% of 56G Well then.  Give me a few to get it committed.
  7. Like
    lanefu reacted to MarcC in Helios4 Support   
    Just to say my batch 3 is working great !
    I just got the Helios4 to boot Archlinux (thanks Gontran !) directly from a SSD on sata1, thanks to @aprayoga ealier tip in this thread about using the scsi command in uboot. That's nice, no more microSD card !
  8. Like
    lanefu reacted to jimbolaya in Helios4 Support   
    I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.
     
    One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.
     
    I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?
     
    If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?
  9. Like
    lanefu reacted to drice in Hardware Graphic/Video Acceleration in H3 Mainline   
    After doing a lot of reading (documentation and code) regarding the Cedrus driver (sunxi-cedrus), LibVA V4L2 Request API driver (libva-v4l2-request), VA-API, and interfacing with video players, I think most of the work will involve VA-API and interfacing with the video players. Or more precisely, updating the video players to interface with the LibVA driver in a way that works with the V4L2 Request API. Based on my testing, the Cedrus driver in sunxi-dev (5.2.6 - MPEG2 only) is working with the native V4L2 Request API as shown by testing with v4l2-request-test and the preset slice data included with that tool. When I run the test, I get hardware accelerated full screen output via DRM.
     
    But so far I haven't been able to get any video playback to work with VA-API in mpv or vlc. mpv fails with "device or resource busy" when calling v4l2_set_format() in X11 and says that the hardware decoder isn't compatible with DRM. vlc fails after rendering the first frame with "buffer deadlock prevented". I still have more reading to do, and I have a few things to try that would be as simple as compiling the players with a few additional options set. But if that doesn't work this could end up being a complicated problem to solve.
  10. Like
    lanefu reacted to Hijax in THE testing thread   
    Status update. DHL parcel received. New boards photos: 
     

     
    and SD adapter inserted into Rock64

     
    Now I am waiting for remaining components then soldering/assembly will start. 
  11. Like
    lanefu reacted to Igor in [RFC] New Naming Convention for Kernel Source Trees   
    Best so far I would say.
     

    Even we are close or at consensus, let's keep it open. There is no rush to implement this. I would prefer to clean up some other stuff before jumping on this.
  12. Like
    lanefu reacted to gprovost in [RFC] New Naming Convention for Kernel Source Trees   
    I guess we will all have different opinions on the matter but I feel we still forgot to see it from user perspective.
     
    I don't really agree on using debian-like denomination for out use case. We are talking kernel here with a naming system to measure hardware support maturity. It's not because a kernel only supports 60% of the feature of a board that it means it's Unstable. Same the other way it's not because a kernel version support 80% of the feature that it means it's Stable. Using Debian convention will just confuse user because the meaning in reality will be pretty different.
     
    I agree that Next is the most confusing name as for now.
     
    As for Default, I like the idea of renaming it Legacy, and loosen up a bit the definition... because in my case Helios4 has nothing to do with Vendor BSP.
     
    Again let's take a one concrete example. Helios4. latest release (v5.91) is as follow
    Default : U-Boot 2018.11 + LK Mainline 4.14.y (100% hardware support) Next : U-Boot Mainline 2019.04 + LK Mainline 4.19.y (100% hardware support) Dev : U-Boot Mainline 2019.04 + LK Mainline 5.x Let's put aside Dev, because personally I feel Dev meaning is pretty clear... and end of the day we don't publish dev image. Again let's look at it from user perspective, we aren't building image just for ourselves.

    If today I publish 2 images : Helios4 Default Buster and Helios4 Next Buster, what would drive a User to choose Default over Next ?
    I mean both have 100% hardware support, both are based on LK mainline and LK version that longterm ( actually LK 4.14 is much more Longterm than 4.19 if you look at the LK calendar) and both use latest Debian. You might say the choice is pretty trivial, user should pick up Next. But some users might ask themselves shouldn't I use Default since it seems to be the default choice (or in other word recommanded choice).
     
    Maybe it won't sound fancy, but I feel it's the following naming that matches the closest to what the builds really are, and it should be quite clear to user what is what and what he should pick. (Ok maybe it applies better to Helios4 use case than other).
     
    - Legacy
    - Current
    - Dev
     
  13. Like
    lanefu got a reaction from TRS-80 in THE testing thread   
    Im a devops consultant and fluent in Ansible so I think im Obligated in that regard. I can at least handle the plumbing hopefully others can implement the more granular testing once the framkework is in place.
  14. Like
    lanefu reacted to Hijax in THE testing thread   
    Picture of first power / serial board. This is the old design and I am awaiting for new one (just got DHL notification of incoming parcel) 
     
    I expect that till end of August the prototype will be assembled and electrically tested. Then as promised I will publish design and manufacturing files.
  15. Like
    lanefu reacted to TonyMac32 in Bring up for Odroid N2 (Meson G12B)   
  16. Like
    lanefu reacted to Igor in Bring up for Odroid N2 (Meson G12B)   
    Oh, just that?  gr8!
  17. Like
    lanefu reacted to martinayotte in [RFC] New Naming Convention for Kernel Source Trees   
    For me, it is only "naming convention" ... So, I will continue to work on "unstable" images ...
  18. Like
    lanefu reacted to Tido in [RFC] New Naming Convention for Kernel Source Trees   
    @martinayotte, @TonyMac32, @Igor, @chwe, @gprovost, now that you look at it, do you like the idea or do you see some obstacles ?
     
  19. Like
    lanefu reacted to Igor in Forum upgrade planned for May 2nd   
    Updated to 4.4.5
    https://invisioncommunity.com/release-notes/445-r86/
  20. Like
    lanefu got a reaction from Werner in [RFC] New Naming Convention for Kernel Source Trees   
    See conversation in this commit for background
     
    The current default, Next, Dev naming convention for the kernel source trees is confusing, and a bit inconsistent.   I think it's time to rename them and provide clear definitions of what they are supposed to provide.
     
    I'll start with some ideas here:

    Vendor 
     
    This Kernel is currently called Default .  The Vendor kernel would be the BSP-derived kernel or vendor maintained kernel.  Typically there for basic functionality early in a boards life.  Armbian can supply patches for these kernels
     
    LTS

    This kernel is currently called Next.   The LTS kernel would follow a LTS version of mainline or fork.  Ex: 4.19 of Megous's branch for orangepi, mainline:4.19 for espressobin.   This should be our flagship kernel and the only one we "support" for end users.  Armbian can supply patches for these kernels
     
    Unstable
     
    This kernel is currently called Dev.  The Unstable kernel would follow a recent branch or fork of a kernel.  Armbian can supply patches for these kernels.
     
    Mainline
     
    This is new.  It would follow mainline:master.  Its purpose is to provide a 100% mainline experience when practical.  No patches will be supplied by Armbian.
  21. Like
    lanefu reacted to jimandroidpc in Helios4 Support   
    @gprovost I manually made the change and confirmed the encryption. Now transfer speeds are 75-80MB/sec up/down compared to 50-55 on XTS. 
  22. Like
    lanefu got a reaction from Tido in [RFC] New Naming Convention for Kernel Source Trees   
    See conversation in this commit for background
     
    The current default, Next, Dev naming convention for the kernel source trees is confusing, and a bit inconsistent.   I think it's time to rename them and provide clear definitions of what they are supposed to provide.
     
    I'll start with some ideas here:

    Vendor 
     
    This Kernel is currently called Default .  The Vendor kernel would be the BSP-derived kernel or vendor maintained kernel.  Typically there for basic functionality early in a boards life.  Armbian can supply patches for these kernels
     
    LTS

    This kernel is currently called Next.   The LTS kernel would follow a LTS version of mainline or fork.  Ex: 4.19 of Megous's branch for orangepi, mainline:4.19 for espressobin.   This should be our flagship kernel and the only one we "support" for end users.  Armbian can supply patches for these kernels
     
    Unstable
     
    This kernel is currently called Dev.  The Unstable kernel would follow a recent branch or fork of a kernel.  Armbian can supply patches for these kernels.
     
    Mainline
     
    This is new.  It would follow mainline:master.  Its purpose is to provide a 100% mainline experience when practical.  No patches will be supplied by Armbian.
  23. Like
    lanefu reacted to Hijax in THE testing thread   
    First PCB from jlcpcb in on the way.
    Meanwhile I have find some time to sit down on the mSD adapter.
     

     
    Small PCB with JST XH connector. Thus cables between mux boards and those should be 4-Pin JST XH Female Connector Double Ended ones.
     
    An micro SD mux board final design:

     
    And serial mux / power distribution (with I2C interface)
     

     
    For serial / power connection, standard NEMA17 extender cable (4-pin JST XH & DUPONT connectors) will do the job.
    Dupont connector inserted into following pins on the SUT board:

     
    I have ordered 1m cables (JST/JST & JST/Dupont) from aliexpress.
     
     
     
  24. Like
    lanefu reacted to Hijax in THE testing thread   
    JST connectors shall be locked in place and not touched, yes. This is due to the need of having firm board-cable connection, also there is no need to disconnect that.
     
    For power & serial cable, second end I plan to use 4 pin Dupont connectors. This time for easy plugging into SBC 40pin header. 
    Hence, together with uSD card adapter both can be reconnected as many times as one need.
  25. Like
    lanefu reacted to gprovost in Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking   
    https://wiki.kobol.io/cesa has been updated to be ready for upcoming Debian Buster release. For Debian Buster we will use AF_ALG as Crypto API userspace interface. We choose AF_ALG for Debian Buster because it doesn't require any patching or recompiling but it comes with some limitation. While benchmark shows in some case throughput improvement with AF_ALG, the CPU load is not improved compared to cryptodev or 100% software encryption. This will require further investigation.
     
    So far I didn't succeed to enable cryptodev in Debian version of libssl1.1.1... Need further work, and it's not really our priority right now.
     
    Also for Debian Stretch I updated the prebuild libssl1.0.2 debian deb to latest security update release (libssl1.0.2_1.0.2s). Can be found here.
     
     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines