chwe

Moderators
  • Content count

    224
  • Joined

  • Last visited


Reputation Activity

  1. chwe liked a post in a topic by martinayotte in pyGPIO - A 'more general' python GPIO library   
    All unused GPIOs are defaulted as normal GPIO, no needs to tweak DT.
    And they can be tested easily using /sys/class/gpio ...
     
  2. chwe liked a post in a topic by TonyMac32 in mali drivers for mainline linux kernel   
    Any reason you're not using 4.13?  4.14 is still a Dev release, it's not fully patched.
  3. lvmc liked a post in a topic by chwe in Banana Pi Zero   
    it's everything there...  just open your eyes... 
     
    And I don't use it, I was only interested in the script.bin file... It boots,  wifi 'works' but without an external antenna, it's not stable in an urban environment. 
  4. Naguissa liked a post in a topic by chwe in ArmbianIO API proposal   
    I'm currently working on a fork of the pyA20 python library which is used quite often by people here when playing with GPIO, spi or i2c. It's not ready for public at the moment, but it will be soon.  It has an automated board detection, pin naming is consistent so that you can use your python scripts on every supported board without renaming everything. And it has a 'board detection' mechanism to use the right pin mapping during the installation. 
  5. chwe liked a post in a topic by Igor in Forum upgrade   

    Fixed.
  6. chwe liked a post in a topic by Icenowy in Orange Pi R1   
    P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)
  7. lvmc liked a post in a topic by chwe in Banana Pi Zero   
    But BPi-M2+ has 'no voltage regulation' for CPU.

    Which makes it 'not useful'.  Maybe you can fix this issue (and make an annotation in your documentation for this board) when you produce the next batch of this board?
  8. StuxNet liked a post in a topic by chwe in Couple of questions about OPi PC+/ OPi 0   
    1. No (4 non shared USB ports + separate LAN)
    2.  No idea,  not the fields I'm interested in...  (personal opinion H2+, H3 SBCs aren't best for multimedia purposes, but this just an opinion)
    3. No (4 non shared USB ports + separate LAN)
    4. No (it's also called CSI, but not the same)
     
    Edit: When you consider using mainline:
    No camera support at the moment (to my knowledge) No hardware accelerated video decoding
  9. chwe liked a post in a topic by tkaiser in Couple of questions about OPi PC+/ OPi 0   
    We have a search function (in the upper right of this web site, eg. enter tvheadend there if you need information about tvheadend), we have some documentation, we have device pages like this where you should click on 'hardware details' that should be able to answer all those questions.
     
    If you expect Orange Pis to be 100% compatible to Raspberry Pis then better stay with what you have now. Also due to this here being a way smaller community you'll need to help yourself a bit to succeed (use the search function for example).
  10. lvmc liked a post in a topic by chwe in Banana Pi Zero   
    Mikey should think about this lines too:
    [uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<3><1><default><default> uart_rx = port:PA14<3><1><default><default> uart_rts = port:PA15<3><1><default><default> uart_cts = port:PA16<3><1><default><default> From your schematics, PA15 & PA16 are expanded on 'CON 2' header, so it would be no problem to use it (uart_type = 4).
     
    Further (line 790 to 793):
    [s_rsb0] s_rsb_used = 1 s_rsb_sck = port:PL00<2><1><2><default> s_rsb_sda = port:PL01<2><1><2><default> half of this bus is now used for switching between 1.1V & 1.3V so s_rsb_used = 0 cause you can't use it for other porpuses.  
     
    Maybe if you want to improve things, Mikey  could also set a 1 (w1_used) here:
    [w1_para] w1_used = 0 gpio = 10 gpio = 10 means that one-wire would be available on (PA10, means PIN35 on your expansion header) or to make it even easier for the users set 'gpio = 20' (PA20) which would than be the nice PIN40 on this header. But you have to inform your users that they should set CPU min freq to 480MHz (otherwise your Forum would be full of stuff like 'why's one wire disappearing constantly?' ). This might be something for your gitbook pages. Explaining the users 'how to connect something like DS18b20 to my BPi M2 Zero'
     
     
  11. chwe liked a post in a topic by Igor in Debian/Ubuntu Orange Pi Zero/R1 (Allwinner H2+) ver. 3.4.113-sun8i (armv7l)   
    https://docs.armbian.com/Developer-Guide_Build-Preparation/
     
  12. Larry Bank liked a post in a topic by chwe in Banana Pi Zero   
    I downloaded your image from your google drive yesterday (btw google drive is an awful storage place when you've to download large files from a console, but this small python tool helps a lot).  I mounted the fat partition and extracted script.bin from /bananapi/bpi-m2z/script.bin. A quick look at it wasn't that exciting.
     
    3. line:
    machine = "Banana Pi BPI-M2-Plus" false board name as Thomas said on one of his first posts in this thread (July 30). 
     
    183 - 190:
    [uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<3><1><default><default> uart_rx = port:PA14<3><1><default><default> uart_rts = port:PA15<3><1><default><default> uart_cts = port:PA16<3><1><default><default> defined as uart_type 2 but rts and cts are defined. 
     
    start at line 739:
    [dvfs_table] pmuic_type = 0 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 240000000 LV_count = 6 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 1008000000 LV2_volt = 1300 LV3_freq = 912000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 LV6_freq = 240000000 LV6_volt = 1100  
    The only place where people see that it should be PL01 instead of PL06 is your schematics and armbians forum. 
     
    If you still asking yourself why Thomas is attacking constantly your company, this might be a valid reason. Besides playing with SBCs I'm doing in science where we have a peer review process for everything we publish.  As a peer reviewer, I would reject your 'script.bin paper' with a short comment that you should do your homework first before I have a more detailed look at it. 
     
    FYI: I didn't check everything in the script.bin and I'll not do it until you showed that things are improving. 
    BTW: PL06 is used as USB0-id, I've no clue what happens when this pin goes from high to low (or vice versa) every time the CPU clocks up if you have a USB device connected to this port...  (EDIT: https://www.maximintegrated.com/en/app-notes/index.mvp/id/1822 could be interesting if you use USB as OTG with changing roles... )
  13. Naguissa liked a post in a topic by chwe in Banana Pi Zero   
    It's not about last chance, I think you missed a key point there.  Support for a new board is mostly a question of time and knowledge of an experienced developer taking care of a SBC.  When you've a look which BPi boards are supported with a 'stable' armbian. You could see that there are a few of there boards:
    BPi M2+ (H3) BPi M2 (A31s)
    BPi Pro (A20, actually a lemaker, not SinoVoip product, correct me if I'm wrong here...)
    BPi + (I think this is called M1+ by SinoVoip, also a A20)
    BPi (should be the one called M1 by SinoVoip, A20)
     
    IMO, the reason why you see so much more OPi boards supported by Armbian is the following: They have a real conservative 'board design philosophy' - more or less every board from xunlong is based on H2+/H3 which as Thomas said, makes it easy to add support (as long as you've correct schematics, or as xunlong does it 'never change a winning team' - you know one, you know most OPIs ).  SinoVoips approach to invent '20 different wheels for 15 use cases' (means having a bunch of different SoCs on their SBCs,  and therefore many different board designs make it harder to support their boards).  
     
    I bought a BPi Zero (and paid the full price  ) and I'm sure that I'll have a dedicated armbian running on it (I think I'm able to adjust the basic things I need to get my needs running if nobody from the 'core developers' are willing to do it) but I'm not able and passionate enough to be a 'maintainer' like @TonyMac32 for the tinkerboard (actually a board which has also a lot of design flaws ). Means I'll not spend much time on things I'm not interested in and I don't feel responsible to answer every question about it on the armbian forum.  Naming your images Raspian (something Xunlong and SinoVoip do) is IMO false advertising. First their boards are not RPIs. Second, Raspian is built on a (more or less) recent kernel (at least 4.x). Third, GPIO libraries  are working out of the box (which is often not true for these boards) and last, things like mathematica,  Node-Red & Wolfram Alpha works also out of the box (I never checked all these things on the OPis or BPis Raspians, but for the kernel it's sure - most OPis running the outdated 3.4.39 kernel BPi0 improved here slightly with a 3.4.113 kernel). Both companies don't shine on software support (but Xunglongs 'conservative design strategy' makes it easier to support their boards), so improvement there would be really appreciated.
     
    Annotation: this part of my post has some sort of humor, sarcasm & frustration in it, if you can't deal with it, just don't read it.  
    A basic 'board bring up' for an H2+/H3 board (as repeated a way to often in this thread  ) is not a huge deal. But maintaining the community support clearly is (just have a look here how many questions come up for *random SBC*). More or less every week a thread 'why wifi on OPi0 does not work?' (shitty XR819 just use search engine) or 'why armbian does not support RPi display on tinkerboard?' (armbian is not the board maker, this is a spare time 'job' we don't have time to do everything in minutes,  btw. congrats to @tonymac32, you got it work! I think we're now close to ASUS advertised RPi compatibility with the tinker ).  So, the more boards armbian supports, the more time experienced supporters of armbian are absorbed by answering this questions, testing images etc. (Thomas would say, 'waisting time'  ).  And what's also clear,  the more a board is claimed to be raspberry compatible, the more 'inexperienced users' joining armbian (best example Tinkerboard).  This might avoid someone like Thomas being excited adding support for such a board cause he knows the consequences - more 'inexperienced users' (sometimes too ignorant following basic instructions from an experienced armbian supporter -  see here for some examples), expecting that everything on armbian should work similar than on raspian cause boardmaker claimed RPi compatibility and armbian is based on debian. So, 'no difference to *random RPi*'  (except, it has to be cheaper than a RPi and I want 'real SATA' on my board).  That's why I still like the RPi - more or less everything they advertise works on their boards. It's not the most powerful board (you get more powerful & cheaper SBCs on an H2+/H3 basis) but most things the *average SBC user* can imagine is solved by someone from the RPi world and they've targeted the 'noob problems' (it's a shame that they still use the micro USB connector for the RPi3 but nevertheless they have a 'protection mechanism' to avoid underpowering the board - one major issue on cheap H2+/H3 boards here at armbian). 
    I hope you see the point in all this *random BS I talk here*
    Board bring up would be easy Support needs a lot of time more *average RPi users* means more ignorant users (not all of them, but part of them are) the more a bord is claimed to be 'RPi compatible' the more *average RPi users* will show up here - the more time is needed to explain to them that verdor claimed RPi compatibility doesn't mean that this is true nor armbians major goal is to be 'RPi compatible'  
    Seems that they run out of their 'good eMMC' chips.   (maybe I should sell my 'old' OPi Pc+ on ebay, advertising that it is a 'fast one'  ). 
     
    IMHO no! The only reason using NanoPi Duos 'motherboard' is during product development to get 'all features' easily accessible. If you still use it 'on production scale' of your project, just go for an *random H2+/H3 SBC* which deploys this features without a 'motherboard'. The main benefit of those SBCs is their size with a drawback that not everything is deployed on the board (this could also be a benefit if you don't want to have things deployed on the place the boardmaker deploys it, e.g. ETH is deployed 'on the false edge' for your project). But this is clearly a personal opinion....  
     
    @Lion Wang - take care of this sort of feedback. At the moment, your BPi zero is a 'quad-core rip off' of the RPi 0 for a higher price than the original which would make it hard for most SBC customers to buy it instead of the 'original'. The fact that the camera connector is not compatible to RPi makes it even worse for a lot of use cases (you'll find a generic RPi compatible camera for ~6$ on aliexpress but a BPi compatible camera is in the range of 20$).  RPis videocore GPU works on recent kernels whereas Mali is 'work in progress' (but to my knowledge, nobody works really on it.  ).  So, your board needs some 'features' which makes it interesting for people which are annoyed by the RPi0. This could be (personal opinion).
    eMMC instead of/combined with SD card  ETH on a pinheader (which you have) more than one USB port (maybe also on a pin-header) etc.  I said it once and now the second time,  don't bring this discussion to personal level between you and him which will end similar to the 'famous' BPi-R2 thread we had here and @Tido or myself will close it cause it's only about you don't understand why Thomas doesn't like your products and you're claiming that he must work for Xunlong.  This thread is a little bit like a baseball game - a lot of boring, not BPi0 related, stuff (maybe also provided by myself  ), and some new information we didn't know before (e.g. ETH is accessible through pin-header, 1.1/1.3V cpu regulation is on PL1 instead of PL6, first version of schematics). But as a real American @TonyMac32 can explain to you what happens in baseball after strike two...  (hint:  I'll close the thread maybe only for a 'cool down time' maybe forever cause I don't think we need a second 'BPi-R2 thread' again).  If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it. 
  14. Lion Wang liked a post in a topic by chwe in Banana Pi Zero   
    Nice to get a fast response. But when you've ethernet there, this should be on your schematics! and described somewhere.  Most people would expect that the connector might be for powering (or maybe the USB otg). And to improve things, make sure that this information is not only visible here in the armbian forum.  It should also be in your documentation for this board. 
  15. Lion Wang liked a post in a topic by chwe in Banana Pi Zero   
    Maybe not for your use cases but for others. Not everyone has the same needs... I see use cases where size and wifi matters... Since OPi0 has heat issues,  and both other cheap small boards (opi0 and nanopi) have the annoying XR819 wifi.
     
    don't start this again...  Thomas and you will fight on a personal level again, and @Tido will close the thread again...
     
    Doesn't make sense... If they have an interesting board, I'm sure people from the Armbian community will work on this board (maybe not Thomas but others.. ) And as @@lex said... Edit: Getting basic armbian support for this board should not be that much work. Starting with a similar board (1.1V/1.3 V regulation) add wifi and configuration of fex for the pinheader and you'll have a basic armbian image for this board. 
     
    I appreciate this, so let's start with the 4pin connector from my last post. 
     
    FYI: Short version of the post with the picture which is lost somewhere in the www nirvana during upload.  I was too annoyed to write everything again...  
  16. chwe liked a post in a topic by TonyMac32 in Asus Tinkerboard   
    I've added RPi 7" DSI touchscreen support to the 4.4 kernel, I will work on patching it into mainline as well, but no guarantee, it is not the cleanest of drivers (requires modifying the dw-mipi-dsi.c file), and this patch is MiQi safe.
     
    This would have been done earlier, but I had to make sure it would work by declaring the hardware in the device tree instead of explicitly in the kernel source. (and make sure it didn't break the MiQi)  As it turns out, I was incredibly overthinking the problem, cheers to the Linux kernel devs.
     
    Tested OK with this configuration: 
    Tinker with DSI Display Tinker with DSI Display and HDMI display (displays are "on top of each other" on first boot, drag the smaller display around in the desktop settings and you have an extended desktop) Touchscreen driver is not robust against this configuration.  It tries to cover the full extended desktop. Tinker with only HDMI (no ghost devices/errors/crashes. Tested to be sure the drivers could cope with not finding the hardware, as the device tree entries are still there) MiQi (as it does not have the DT entries, merely a test to make sure no source/driver interactions)  
  17. chwe liked a post in a topic by Igor in Mali support announced for mainline (Allwinner SOC's)   

    We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
    https://www.armbian.com/search_gcse/
     

    To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

    Donations are like love. Unconditional.
  18. chwe liked a post in a topic by peter12 in Clone/backup bootable microsd card - make as small as possible image   
    Hi there, this very short tutorial is a solution when you need to backup/clone/save as small *.img file as possible of your whole fully bootable system (e.g. you have 8GB card but you want to make smaller system image for 2GB card). And another reason why I created this tutorial - I need to burn the same image to many microsd cards.
     
    I am using Windows (yup, hate me know)  and Debian in these steps:
    Put your microsd card to Windows machine and make image of card with Win32diskimager. If your card is e.g. 8GB, you get *.img file with the same size (my name backup.img). Now in linux maxine (in my case Debian virtual machine) we are going to work with backup.img file. Run these commands in terminal (if you are not root use sudo at the start of each line) modprobe loop losetup -f losetup /dev/loop0 backup.img partprobe /dev/loop0  
    Run gparted with this command and move slider of main partition to the left to make partition smaller (leave some space, e.g. I left 400MB free space)
    gparted /dev/loop0 Click on Apply once you are happy with it.
    We can unload loopback device now
    losetup -d /dev/loop0  
    With fdisk find out end of last block
    fdisk -l backup.img   
     In my case last block is 3571711 so I run command 
    truncate --size=$[(3571711+1)*512] backup.img  
    Done! Size of your backup.img file should be now about 1.5GB.
     
     
    You can burn this new backup.img file to another (or the same) card/s now. In my case I dramatically reduced time needed for burning data to many many cards (it saves hours/days when you need to burn a lot of microsd cards). Enjoy!
     
    P.S. this can be done also with just Debian, so no need for Windows, in this case you just need to make first step with backup.img with linux command (e.g. dd). And of course you can set up a script on your newly burned card to expand system partition to the whole microsd size during first boot, if needed. 
  19. Tido liked a post in a topic by chwe in NEW SD cards - only 1 partition   
    which brands? models? Would be interesting so that others can try to reproduce your findings.
  20. chwe liked a post in a topic by mariuszb in Hdmi 1280 x 800 display   
     
    Hi, I'm leaving for a few days , so given parameters it might be someone needed. For these parameters, display works with 1280x800 , but I do not know if these values are optimum values. I'll do some more tests after returning, but but for now it works correctly     {HDMI1280x800_60, 0,83460000, 0, 1280, 800, 1680, 200, 64, 136, 828, 24, 1, 3, 1, 1, 0, 0, 0} {{Video ID  ,4 , 0, 96, 5, 3, 3,  1,   1, 0,  0,  0, 144, 64, 136, 32, 28, 1,  1 }} PLL_VIDEO 334
  21. chwe liked a post in a topic by botfap in [SOLVED, PSU issue, SMB server issue] Asus thinkerboard hangs   
    Problem is that there are at least 4 different RasPi PSU's that I have seen and not a single one of them is suitable for powering the tinkerboard which draws upto 3 x more current under load than any of the Pi models. The 2.5A Pi PSU we tested (comes with the Pi3 Kit) would only actually deliver ~1.4A reliably and when it gets hot it gets very unreliable. Thats why I asked  for the numbers off the PSU. The most power hungry PI model (3B) uses 30-40% of the total current than the tinkerboard at max load (see attached chart). Even if you connect the Pi PSU through the GPIO pins there still isnt enough current from any Pi branded PSU I have seen to power the tinkerboard reliably. As a general rule, RasPi accessories (like the boards) are made to very low standards and budgets and should be avoided.
     
    If you can provide details for me to replicate your software, ramdisk, swap and workload I can have a look at reproducing the problem and finding a solution or at least a cause. The fact you have swap on SD make me shudder!
     
     

  22. willmore liked a post in a topic by chwe in orange pi zero, upgraded kernel permanently broken wifi   

    So, 8-12$ (depends if you calculate the price for an orange pi with or without shipping) is expensive? I do some testings with the opi pc+ in AP mode, but to be  honest I like the 'connecting sbc to access point wired, and connect nodes normally to this ap' approach more. It's less load on my SBC and capabilities of my AP are better (throughput, which is of no interest in your case but ping seems also to be better).
     
    Just have a look with the google search engine here if you find something that fulfills your needs. It's a bit out of my knowledge cause my sbcs are mostly wired.  
    https://www.armbian.com/search_gcse/
  23. willmore liked a post in a topic by chwe in orange pi zero, upgraded kernel permanently broken wifi   
     
    When you started with a freshly burned SD-Card running mainline something like this should appear within your first login.

     
    If you did it via armbian-config, something like this appears:

    or this (if you moved to nightly):

    And if you had a brief look on armbian download page you would see something like this:

    and this:

     
    I can't repeat your experiment, booted a 4.11.7 image (wifi was visible, cause not deactivated on this image), followed by booting a 3.4.113 image and wifi worked, without any issues (no long-term test!!).. So it might be hard to figure out why wifi on your board is broken now. If you look around here, you'll see that wifi on this board is somehow questionable (just an example, you'll find multiple threads about this issue).
    A personal opinion: Using a older nightly with 4.11.7 just cause wifi wasn't deactivated by default isn't really smart (you got maybe wifi, but cause you've to freeze kernel and board upgrades, you'll miss all the improvements on board support). It seems that the wifi driver for XR819 is in such a bad shape that nobody wants (or is able) to work on it. If I would need wifi on one of my opi0, I'd go for a usb wifi stick. If I would need wifi permanently, I'd go for another board with better wifi support.
     
  24. chwe liked a post in a topic by botfap in Asus Tinker Board HDMI (hotplug/etc)   
    I havent tried Armbian yet but I had the same problem when I created a buildroot based firmware using eudev.
     
    I added a new udev rule:
    SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi-toggle" in a new file (hdmi.rules) in /etc/udev/rules.d
     
    Then save the bash script below to /usr/local/bin/ which will be triggered by the udev rule and toggle the display
    #!/usr/bin/env bash USER="$(who | grep :0\) | cut -f 1 -d ' ')" export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 ########### Settings ########### # Use 'xrandr' to find these DP="DP-1" VGA="VGA-1" HDMI="HDMI-1" INTERNAL_DISPLAY="LVDS-1" # Check /sys/class/drm for the exact location DP_STATUS="$(cat /sys/class/drm/card0-DP-1/status)" VGA_STATUS="$(cat /sys/class/drm/card0-VGA-1/status)" HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)" # Do no change! EXTERNAL_DISPLAY="" # Check to see if the external display is connected if [ "${DP_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$DP fi if [ "${VGA_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$VGA fi if [ "${HDMI_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$HDMI fi # The external display is connected if [ "$EXTERNAL_DISPLAY" != "" ]; then # Set the display settings xrandr xrandr --output HDMI-1 --auto else # Restore to single display xrandr --output HDMI-1 --off fi exit 0  
  25. pfeerick liked a post in a topic by chwe in New OPi Zero - Yet another high temperature issue...   
    legacy
     
    For everything inside a case I can't give you an answer, my OPi laying somewhere around. But as bozen mentioned, this boards aren't running stable inside a case and I think he tested it more than once. At the moment I wouldn't recommend this board for high load use cases. Seems that rev. 1.4 is somehow a design failure. I have one running since ~20d stable (without case, last reboot was due to updates not crash, legacy) with node-red on it over ETH without problems. You can try with a heat sink and set max_freq with h3consumption to 912MHz (this should aviod feeding the CPU with 1.3V) but I'm not sure if this is enough to avoid overheating.