tkaiser

Members
  • Content count

    4536
  • Joined

  • Last visited


Reputation Activity

  1. Larry Bank liked a post in a topic by tkaiser in 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. tkaiser liked a post in a topic by Larry Bank in ArmbianIO API proposal   
    I'll explore fixing the board name situation using your suggestion. Another reason I shared ArmbianIO as open source was for other people to contribute. @sgjava has already made some significant contributions such as Python and Java wrappers for it.
  3. tkaiser liked a post in a topic by Larry Bank in ArmbianIO API proposal   
    ArmbianIO is not a fork of WiringOP. I wrote ArmbianIO because of the terrible situation with WiringOP and WiringNP. Using the BCM numbering on Allwinner boards is understandable for RPI compatibility, but limits what you can do with non-BCM chips. I thought a fresh start which treats all boards as unique and allows more than 40-pins of GPIO header would be wiser than another "crutch" of a hacked up WiringPi copy. I have a wide variety of boards and ArmbianIO (even running on Raspberry Pi boards) allows a consistent way to work with GPIO/I2C/SPI. I know that when I hook an LED or switch to a GPIO pin, I can run the same code on any of my boards and connect it to the same header pin and it will work without modifying my code.
     
    chwe: splited from https://forum.armbian.com/topic/6197-hardware-line-is-missing-on-proccpuinfo/  cause I think it's better to keep this in this thread.
     
  4. tkaiser liked a post in a topic by zador.blood.stained in Hardware line is missing on /proc/cpuinfo   
    Or, as I suggested before, read /proc/device-tree/compatible (null-separated array) which contains both the board name and SoC name, so even if the library doesn't support a new board it can at least support SoC specific pin map.
  5. manuti liked a post in a topic by tkaiser in 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)
  6. manuti liked a post in a topic by tkaiser in 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. trohn_javolta liked a post in a topic by tkaiser in 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)
  8. trohn_javolta liked a post in a topic by tkaiser in 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. Naguissa liked a post in a topic by tkaiser in Odroid HC1 SATA disk switches between sda and sdb   
     
    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!
  10. Naguissa liked a post in a topic by tkaiser in Odroid HC1 SATA disk switches between sda and sdb   
     
    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!
  11. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    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
  12. tkaiser liked a post in a topic by Larry Bank in ArmbianIO API proposal   
    A new wrinkle to this idea. I've been working with Arduinos lately and thought it would be useful to extend the ArmbianIO concept to use them as "slave" interfaces for sensors/displays/etc. This is an experiment I'm working on and would like some feedback. The idea is that the ArmbianIO API can be used identically on Windows/Mac/Linux. On a remote setup, an Arduino will be used as an I/O slave listening for commands over the serial port. The ArmbianIO you compile on your PC will translate the I2C/SPI/GPIO functions into strings of commands/data over the serial port. Below is a video of my https://github.com/bitbank2/oled_example project running on my Mac and the same exact C code running on my Orange Pi Lite board next to it:
     
     
    Please let me know your thoughts.
  13. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    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
  14. manuti liked a post in a topic by tkaiser in Meltdown and Spectre   
     
     To quote the most important sentence there (emphasis by me):
     
    So how is Armbian affected?
    Allwinner A10 boards (Cortex-A8): easy solution, stop supporting them, it's only one board left AFAIK Micro-USB powered support nightmares called MiQi and Tinkerboard (Cortex-A17): in my personal opinion support for power hungry boards with Micro-USB for DC-IN should be phased out. Once this is done problem solved ODROID-XU4 (Cortex-A15): stop supporting legacy kernel and switch next from 4.9 to 4.14 (in the hope of an upstream fix arriving soon) That's it.
     
    BTW: it's frustrating how much attention Meltdown and Spectre get compared to more severe security issues  
     
    Edit: I forgot i.MX6 (Cortex-A9). Given how 'popular' these boards are these days the most easy 'solution' would also be to phase support out.
  15. manuti liked a post in a topic by tkaiser in ODROID HC1 / HC2   
    Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.
  16. guidol liked a post in a topic by tkaiser in Can you install Armbian to NanoPi Neo Core eMMC?   
     
    Which image? Did you realize that Armbian currently neither supports Core nor Core2?
     
    If you use an image with eMMC support (eg. those for NEO Air) it should just work, if you use any image without eMMC support (eg. those for NanoPi NEO) it can't work.
  17. James Kingdon liked a post in a topic by tkaiser in ODROID HC1 / HC2   
     
    If you look at page 1 of this thread there are thermal values from my 1st HC1. When my HC2 arrived some weeks ago I noticed a lot higher temperatures reported in the beginning. I carefully 'massaged' the PCB and this did the trick: temperatures later only a few degrees above HC1 (which is to be expected due to the additional 12V/5V DC-DC converter). So trying to get a better contact between SoC and heatsink (spreading the thermal paste) is always a good idea if the temperatures you get are a bit off.
     
    https://forum.odroid.com/viewtopic.php?t=27665
  18. manuti liked a post in a topic by tkaiser in Beelink X2 doesn't boot Linux   
     
    Useless unless you want to 'restore performance' or perform the equivalent of TRIM on an SD card (if the card supports it).
     
    It gets pretty boring to repeat everything again and again since it's written in Armbian's documentation: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity
     
    TL;DR: Check download authenticity/integrity, check your card with  F3 or H2testw, burn with Etcher. Everything else is a waste of time.
  19. Tido liked a post in a topic by tkaiser in Banana Pi M2+ H5   
     
    Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different)
     
    So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?
  20. tkaiser liked a post in a topic by Larry Bank in ArmbianIO API proposal   
    I wrote it specifically for Armbian, but it doesn't hurt to support RPI boards. This way I can test my code across a wider range of boards. I have a desk full of ARM SBCs from various vendors (including RPF). I tend to write code to support the hardware I own.
  21. ebin-dev liked a post in a topic by tkaiser in Looking for an enclosure for espressobin   
     
    And guess what: I have a huge box here labeled 'PC-Schraddel' (PC junk), just checked it for those cables and to my surprise I found in there my EspressoBin and also the right cable with 2 female Molex jacks:

  22. ebin-dev liked a post in a topic by tkaiser in Looking for an enclosure for espressobin   
     
    And guess what: I have a huge box here labeled 'PC-Schraddel' (PC junk), just checked it for those cables and to my surprise I found in there my EspressoBin and also the right cable with 2 female Molex jacks:

  23. tkaiser liked a post in a topic by zador.blood.stained in Looking for an enclosure for espressobin   
    Looks like it can be easily solved by cutting a cable with 2 female Molex connectors from an old ATX power supply and then using a pretty common Molex male to SATA power cables or adapters.
    You may also find a cable with both female Molex and SATA power on it, but AFAIK modern ATX power supplies usually have separate cables for Molex and SATA power, especially since "full" SATA power has additional 3.3V line not present on 4pin Molex connectors.
     
    You can call it "wrong" but I did a quick search and I couldn't find a Molex female connector (of this type) for soldering on PCB. Of course you could use any other connector there or solder a piece of cable to the PCB with a Molex female connector on the other end, but I'm not sure if those are better options than the current one.
  24. umiddelb liked a post in a topic by tkaiser in Looking for an enclosure for espressobin   
    Nice. How did you solve the problem of the stupid Molex male power connector? And do you sell these things?
  25. tkaiser liked a post in a topic by ebin-dev in Looking for an enclosure for espressobin   
    We have produced a few minimalistic housings for the EspressoBin (120x42x81mm) with space for a 2.5" drive using a CNC molding cutter.
    Passive cooling of the processor and topaz switch by thermal coupling to the housing works well (housing temperature 31 degrees, ambient temperature 20 degrees).