tkaiser

Members
  • Content count

    4536
  • Joined

  • Last visited

6 Followers

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

8645 profile views
  1. testers wanted ArmbianIO API proposal

    I really hope ArmbianIO spreads widely. And relying alternatively on /proc/device-tree/* might help with user adoption. For example once DietPi users start to use ArmbianIO it could be surprising that ArmbianIO only works on approx half of the boards DietPi 'supports' (since DietPi relies on Debian OS images found somewhere or uses Armbian's build system to create crippled Armbian images with the DietPi menu stuff on top sold then as 'DietPi' to their users -- so if their OS images started as Armbian there will be /var/run/machine.id... otherwise not). BTW: In Armbian for all the Allwinner boards that run legacy kernel we tried to use exactly the same string as /proc/device-tree/model to let this method work regardless of legacy or mainline kernel. Since other projects out there (H3Droid, RetrOrangePi, Lakka) also use our fex files they should become compatible to this 'other fallback' too (at least that was my intention behind these adjustments made a while ago). Some details: https://tech.scargill.net/banana-pi-m2/#comment-27947
  2. testers wanted ArmbianIO API proposal

    Relying on /var/run/machine.id while working with Armbian might not be a good idea since we considered this feature already 18 months ago somewhat deprecated (when we turned armhwinfo into tuneperformance and stopped all auto detection at boot -- currently it only transfers info from /etc/armbian-release to /var/run/machine.id). So the better idea is to rely alternatively on /proc/device-tree/model or compatible (this will be fed with mainline kernel from the string defined in DT, on Raspberries the mythical firmware does some additional 'magic' and also allows you to differentiate between different board revisions based on autodetection or let's better say reading out the preprogrammed 'Hardware Revision Code')
  3. Hardware line is missing on /proc/cpuinfo

    As already suggested to @Larry Bank for his ArmbianIO project a while ago: eg. checking for existence of /proc/device-tree/model and reading the string from there. The DT node exists for a reason.
  4. There's nothing special. Simply stay away from all proprietary crypto modules and choose an ARMv8 SoC with support for ARM's crypto extensions. Reasons why: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829
  5. Orange Pi Zero Plus / H5 Chip

    Can you please provide output from ls -la /etc/armbianmonitor/datasources/soctemp
  6. Support of Raspberry Pi

    You might better try to educate yourself about what really happened. Bananas and Oranges are Cubieboard descendants which itself is in a line with Mele A1000 (or more in general: Allwinner A10/A20 based Android devices that were popular in China and were exported later by Tom Cubie which kickstarted more or less linux-sunxi community, Cubietech and sites like CNX). These origins on A10/A20 happened in 2012 when RPi software support was still very limited. Below one rackmounted Mele A2000 cluster (real Ethernet and real SATA combined with SSDs made the difference to toys): Even the power plug used on Bananas and Oranges is inherited from those first Mele TV boxes! At the time RPi was in early development Beagleboard was already there, ODROIDs were already there and in China they had something similar to RPi already years before (QQ2440 and Mini2440 are FriendlyARM products, yes the company now selling NanoPis since Westerners are that stupid that they only can accept a good SBC design if it has Pi in its name) When speaking about RPi it's more or less about Western perception and of course marketing (that's where the RPi Foundation really excels)
  7. ethernet connection keeps dropping out.

    I was answering not to you but to one of those stupid 'network manager bashing' posts. But thanks for reminding me to stay away from H3 forum (or this forum at all).
  8. ODROID HC1 / HC2

    HC2 is now officially available: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472 (see especially mechanical incompatibility note for few 3.5" HDD at the bottom)
  9. Network Manager woes

    Sounds like you were running into the bug (or settings mismatch) referenced at the end of https://askubuntu.com/questions/842773/ubuntu-server-and-networkmanager (where it's also described how to let NM take care of wired interfaces in Ubuntu Server). Great resource for people struggling with NM concepts is https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-introduction_to_rhel_networking And for experts who prefer anachronistic Debian configuration attempts (fiddling around with text files instead of profiles) the obvious solution is an 'apt purge network-manager && apt autoremove'.
  10. ethernet connection keeps dropping out.

    What a 'valuable' suggestion for physical problems happening on the link layer. Good luck to all blaming software when dealing with hardware issues. @Gord_W: A link is something that is established between two ends. What about the other end? Obviously the problem does not live inside your SBC if you already exchanged them and the problem persists with identical symptoms (hint: look at the other end of the link and what connects both ends: switch/hub port, Auto negotiation/MDI-X settings there, Ethernet cable)
  11. 23% 'one star rating' at least for me is a very clear 'never ever buy such crap' indicator. 2nd 1 star review names the problem already: Can a moderator now please move this whole thread to the subforum where it belongs too? Thanks!
  12. Channels 12 and 13 are only allowed in some countries. You need to adopt to this situation: https://forum.armbian.com/topic/3676-raspberry-pi-zero-wireless-rumors-speculation/?do=findComment&comment=27144 (workaround not a solution)
  13. For 2 HC1 in a pure NAS scenario 6A are sufficient (keep this in mind when you measure consumption at the wall since your oversized PSU is highly inefficient in this low load range and wastes a lot of energy). I write it again one last time: the problem is called underVOLTAGE (and not amperage too low). Meanwell PSUs have adjustable voltage so you need to ensure that your PSU is providing 5.2V and not 4.7V since otherwise you most probably run into the same issues again. Edit: According to the LRS-150F-5 datasheet voltage is adjustable between 4.5V and 5.5V so without a multimeter it's not possible to make any reasonable use of this power supply (since if it's set to much lower than 5V undervoltage at the disk/controller might happen again)
  14. ODROID HC1 / HC2

    There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see here how to do so). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069
  15. There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see above). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069