pfeerick

Moderators
  • Content Count

    145
  • Joined

  • Last visited


Reputation Activity

  1. Like
    pfeerick reacted to Igor in armbian-firmware-full vs armbian-firmware   
    armbian-firmware = minimal blobs that are needed that on-board wireless function + few popular ones = https://github.com/armbian/firmware 
    - full = + everything else https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware.git
     
    You can install one of those, while source package, headers and armbian-config are optional. Also armbian-firmware if your will not be running any wireless.

    Kernel = image + dtb package. Those are the core.
  2. Like
    pfeerick reacted to Igor in Devuan Armbian?   
    There is some movement upstream https://www.debian.org/vote/2019/vote_002
  3. Like
    pfeerick reacted to tkaiser in RockPro64   
    (placeholder for a Board Bring Up thread -- now just collecting random nonsense)
     

     

     
    Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values:
     
    below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong  
    Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.
     
  4. Like
    pfeerick reacted to chwe in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    there you go.. (should be more or less correct, cause only @jmmc works on such features.. )
     
    sure, a not powered board doesn't need much power...  If you want mainline on it, the things you're interested in might come in one or two years (just my opinion)...  To my knowledge, mainlining H6 is still a 'one-woman-show', so better hope that she doesn't looses interest in doing all the work.  
  5. Like
    pfeerick reacted to TonyMac32 in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Because Linux support is not mature for the H6?  It's hard to release a distro for something that doesn't have proper kernel support. :-). 
     
    @Vincen, The Asus Tinker Board, and MQMaker MiQi have experimental video decoder and GPU support.  I'm not as familiar with the other boards to know what they can and can't do in that department.
  6. Like
    pfeerick got a reaction from AnythingIsFine in Rock64 - Armbian eMMC image   
    @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename...
     
    At least it's working now!
     
    Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
     
     
  7. Like
    pfeerick reacted to AnythingIsFine in Rock64 - Armbian eMMC image   
    @pfeerick
     
    Thank you for your time! On the other hand, I do apologize for wasting it.
     
    I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me.
     
    I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot.
     
    On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e)
     
    Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up.
     
    This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC.
     
     
    I think this is default behavior on Etcher on Windows/Linux.
     
    When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out...
    When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself.
     
     
    As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished.
     
    Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs
     
    The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response)
     
    Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs
     
    I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below.
     
    Source.
     
     
    P.S.
     
    I noticed the Rock64 Armbian image is still in its testing phase...
    If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help!
     
  8. Like
    pfeerick reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    Development versions without active DVFS are usually clocked lower so performance wise we are not there yet. Reboot/power off troubles ... noticed.
     

    Yes, ack-ed. I am waiting for another big chunk of free time to dive back in and try to fix this. I also hope that someone else will join and try to move it forward.  
     

    Support is enabled in configuration but it looks like implementation on this board needs few adjustments ... Thanks for trying out.
  9. Like
    pfeerick reacted to Xalius in Pine64+ & Pine64so - uboot - no ethernet   
    I am investigating a weird issue I have with SOPine modules at the moment, GbE works fine on the Baseboard A with 4.15-rc6, but not on clusterboard, I also have an issue with MAC address assignment where the interface drops into monitor mode after a while...
  10. Like
    pfeerick reacted to chwe in New forum UI!!   
    hmm... sounds familiar...  
     
     
    btw.. the like looks a bit messed up (looks quite that they wanna implement more reaction possibilities - I think we had this once before but disabled it?).

    quote is also a mess.. the button shows up random somewhere on my browser..   --> maybe a 'opera only' feature?  
     
     
     
     
  11. Like
    pfeerick reacted to Rfreire in New forum UI!!   
    For what is worth, works great with my intentionally un-updated iPhone 6 iOS 9 
     
    Edit: because... Old people are cranky!!! Get off my lawn slowing down my phone with new iOS, Apple!
  12. Like
    pfeerick reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU
  13. Like
    pfeerick reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    True, I notice that USB3 port was not working. I was happy that it booted in the first place. I already merged into our main sunxi DEV branch (attached back to upstream master) and will try to remake this with a working USB3.
  14. Like
    pfeerick reacted to Igor in Next major upgrade v5.60   
    You need to be an expert to see this  Add EXPERT="yes" to the configuration.
  15. Like
    pfeerick reacted to chwe in board support - general discussion / project aims   
    Let's try it with an example and lock what happens/if it works...   Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test:
    Is it possible to write a proposal what should be done out of it?
     
     
    IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help:
    With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field....  ). 
     
    Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'? 
     
    Internet of shitty Things is the 'new' buzzword...  Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018.  To avoid  more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'.
     
    A few questions:
    Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'?
  16. Like
    pfeerick reacted to jernej in Kickstarter: Allwinner VPU support in the official Linux kernel   
    While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.
  17. Like
    pfeerick reacted to Tido in Kickstarter: Allwinner VPU support in the official Linux kernel   
    beating a dead horse is not going to get you anywhere.
    I rather support Amlogic or Rockchip
  18. Like
    pfeerick got a reaction from Tido in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    Right, why did you post to this topic while I had it open? I think I need to go check my network security now!   
     
    Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data. 
     
     
  19. Like
    pfeerick reacted to Tido in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    and what does stop you of doing so ?
  20. Like
    pfeerick reacted to chwe in IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01   
    I finally gave up playing arround with the MySensors lib.  Main reasons are:
    For every example they use predefined libs (DS18b20, DHT etc.) sometimes no support for updates of these libs.  Things like "This example uses a modified version of the external DTH library, which is included in the MySensors external examples." indicates to me, that this lib has some 'problems', otherwise this should work with the standard DHT lib.  The hole project seems a little bit predefined to me: Use the nodes we think you need, and since I'm not interessted in their nodes it does not make sense for me.  They presented so many examples of nodes, but I never found a example like: how to build your one node (for IoT stuff, where every one, including me, thinks that he would have a better idea how his node should look like, this is IMO the most important tutorial that you should have on your webpage).  I tried to get a DHT11/DS18b20 working on an arduino nano just to give you an example that this setup works, but I failed several times.  Since im not really interessted in the MySensors stuff anymore I would not waste my time for this. If someone tries it and it works, please add it to this thread, it would be cool for others which are interessted in the MySensors stuff!
     
    @pfeerick the finally made it! (ok, not for the toilett, but would not be hard to adapt this..  )
     
    Found on CNXSoft that  BLE is now able to implement mesh networking.  If this will be implemented on the cheap BLE modules (e.g. CC2541) this would be a game changer for IoT thingies... 
  21. Like
    pfeerick got a reaction from Naguissa in Armbian configuration utility   
    Yup, that's what it says at the bottom of the login banner...
     

  22. Like
    pfeerick reacted to Naguissa in Armbian configuration utility   
    armbian-config
     
    Maybe...
     
    Enviado desde mi Jolla mediante Tapatalk
     
     
     
     
  23. Like
    pfeerick reacted to mikemoy in Armbian configuration utility   
    I was informed about Armbian today, and so far from what I am reading it looks very promising.
    I was on the Armbian configuration utility doc page:
    https://docs.armbian.com/User-Guide_Armbian-Config/
     
    But it says nothing on how to start it. whats the command for it ?
     
  24. Like
    pfeerick reacted to ZupoLlask in Pine64 wont boot after update   
    I've just tried to reproduce the problem with a 15cm cable... It still happens easily.
     
    In my case, I don't think it's related with power supply but I'll try to clear that out in the lab.
     
    If it was,  it should happen consistently with several USB devices overloading the power supply with the 4 CPU cores at 100% each, which never occurs.
  25. Like
    pfeerick reacted to ZupoLlask in Pine64 wont boot after update   
    I brought a TTL adaptor from my company's lab and now I can confirm I'm having precisely the same problem described in the OP.
     
    I also found out this thread, which can be useful for other to better understand this issue: https://github.com/longsleep/build-pine64-image/issues/51
     
    As I doubt I have a problem with the power supply I'm using, for now I decided to test another USB cable.
    After that, I'll make proper testings of all the components involved if I need it...