chwe

Moderators
  • Content count

    481
  • Joined

  • Last visited


Reputation Activity

  1. chwe liked a post in a topic by freak in no 4k resolution   
    armbian-config -> system and security settings -> switch to alternative kernels
  2. jkljkl1197 liked a post in a topic by chwe in How do I use the camera on tinkerboard?   
    no, that's the original.. and actually also present in ours, cause we don't install the needed drivers, it is (at the moment) useless. In case you go for the OV5647 camera, you have to change it to something like: 
    camera0: ov5647@36 { compatible = "ovti,ov5647"; reg = <0x36>; clocks = <&ext_cam_clk>; status = "okay"; port { imx219_out: endpoint { remote-endpoint = <&imx219_in>; data-lanes = <1 2>; }; }; }; camera1: imx219@10 { compatible = "sony,imx219"; reg = <0x10>; clocks = <&ext_cam_clk>; status = "okay"; }; Cause the port names in the rest of the DTS (where those ports end) are named imx219.. this should work... Actually a proper naming like camera_out would end in less confusion.. 
  3. jkljkl1197 liked a post in a topic by chwe in How do I use the camera on tinkerboard?   
    camera0: ov5647@36 { compatible = "ovti,ov5647"; reg = <0x36>; clocks = <&ext_cam_clk>; status = "okay"; }; camera1: imx219@10 { compatible = "sony,imx219"; reg = <0x10>; clocks = <&ext_cam_clk>; status = "okay"; port { imx219_out: endpoint { remote-endpoint = <&imx219_in>; data-lanes = <1 2>; }; }; }; huh? both are status okay, but since cam0 has no endnode it will never run out of the box..  So cam1 (which means imx219) is the one looks complete and active.. Or do I miss something?  
  4. chwe liked a post in a topic by Larry Bank in ArmbianIO API proposal   
    ** Update **
    I just added support to the ArmbianIO project for accessing the on-board IR receiver (connected to GPIO PL11 on many Orange Pi boards). Use the macro "IR_PIN" when reading the signal from the receiver (instead of specifying the header pin number). I will be releasing a demo app shortly which receives NEC ir codes without the use of the LIRC driver. My demo app will allow you to connect any IR receiver to any available GPIO pin or use the built-in one if present. The IR codes can be received with a simple 1-bit port without the use of a UART by simply timing the on/off signal to a reasonable margin of error using the Linux clock functions.
     
  5. jkljkl1197 liked a post in a topic by chwe in How do I use the camera on tinkerboard?   
    not with the IMX219, just gave it a short try after weeks of just ignoring it..  It still hangs in oops during boot.. And since I'm to dump build booting images with RKs buildscript... No clue if it's broken at all, or that I'm just to dump.. If someone builds a recent booting Image with their buildscript please post the actual config (not the one I get from the kernel, that's what I can do on my own..  )... 
     
    not with the config we use at the moment, since activating the needed drives will end in not booting images anymore... Even if the camera is not connected.. In case you start to dive into it.. Which cam will you use? Just have a look to the github issue to avoid you doing common mistakes.. I don't have this image anymore to test it with the imx219, but as for my ov5647 I never got it working on their own image. So, I never saw a tinkerboard with their new isp1 driver and a working camera. But maybe, it needs some fresh mind working on it, since I might be to dump and miss something obvious.  
     
    As said before.. Everything is there, it's just a thing to figure out what's going wrong..  You can start to build images on your own and try to figure it out. 
  6. geckow liked a post in a topic by chwe in SBC choice   
    Probably... But my background is chemistry, or to be a bit more precise I did scale up from small to big.. And things you think about there is: What happens when...? 
    your wifi stuff ends in a locked kernel, kernel panic what ever.. the RT capabilities aren't that good as you though and some stuff which keeps the drone in an automatic flight mode doesn't work properly your FS is somehow corrupted and your SBC is for whatever reason not longer accessible during flight. To penetrate WiFi you have to flight over other peoples home (the legal aspect of your project is another field which I don't answer cause I've no idea what is okay and where it gets problematic) but I'm sure you get a bunch of problems when your drone hits somebody and the legal authorities figured out that this happened cause your drone was in an auto-flight mode with a setup which wasn't appropriate. 
    Legal authorities are a bit picky about drones in those days, and you shouldn't gave them a reason that your drone project to make it harder for the 'good guys' developing fancy and nice stuff for drones.  
     
    I would use the SBC on your drone only for collecting telemetric data not needed for a proper flight and your WiFi stuff you want achieve and stick to a flight control which is known that it works well. For sure a more conservative approach, but when it comes to fly over other peoples home safety should be adressed first over the other goals of the project. You wan't be one of this guys:
    https://www.theverge.com/2014/11/13/7205741/i-almost-killed-someone-with-a-drone
     
    In terms of performance (for the network penetrating stuff), I think a cheap H3/H5 board will perform similar or even better.. And if you buy one with a decent onboard wifi, you're able to connect external antennas so you might no need a second wifi attached to it. Maybe a BPi m2-zero? the built in wifi (AP6212) is for sure better than the Xradio stuff on OPi0 (the 'original' not OPi0plus etc. they change wifi chips quite often...  ) or NanoPi Duo, but the board has no official Armbian support and needs some tweaks to get it boot... Whereas boards with a pmic developed for tablets (e.g. often on A64 boards populated) would make sense cause you'll power your board from battery (but I've no clue how good the software side for such boards is, and which board has a known working battery powered possibility)..
     
    btw. the 'new' small beagle (PocketBeagle):

  7. Rfreire liked a post in a topic by chwe in how to change max cpu frequencies tinkerboard   
    comes from this here:
     
    https://github.com/TinkerBoard/debian_kernel/blob/12e65902b4fdcd5211e498ad72543891aebdf596/arch/arm/boot/dts/rk3288.dtsi#L212
    vs. 
    https://github.com/rockchip-linux/kernel/blob/2b3fe0f3500bd62ea6ba3a2da177edda27a8d6ea/arch/arm/boot/dts/rk3288.dtsi#L233
     
    the RK kernel hasn't defined opp>1.6GHz....
    You might adjust it, test if it runs stable and then use it.. This needs at least recompilation of the devicetree.. 
  8. chwe liked a post in a topic by JMCC in S905/X/W/D video acceleration/GPU hw + multi core processing support   
    S905's use SMP, but S912 uses HMP (big.LITTLE architecture). You can google for those terms, and you'll find good explanations about their meaning. That is valid for Armbian as well as any other distro supporting those SoC's.
     
    That means that it is capable to display 4K resolution (that is, 3,840 pixels wide and 2,160 pixels high), at a framerate of 60 or 30 frames per second, and decode video with those specifications. It has nothing to do with the number of CPU cores being used by the system, but with the video decoding capabilites of another component of the SoC, called VPU (Video Processing Unit). Again, google can give you good definitions about these.
     
    I have never tried that. You can try to configure it, and let us know about the results.
  9. chwe liked a post in a topic by arox in SD Card Clone does not work   
    If I understand well ... You fail to clone a Linux image with a Windows/Mac software and complain Linux is bad ?!?
     
    Linux is not user friendly very much (for beginners). It was from the start a unix derivative and a study project from a student. And SBC are not user friendly - and SBC other than RPI are even less. So what use complaining and why not instead buy a full Intel (tm) with Windows (tm) computer ?
     
    And if sofware for your SBC is not as good as expected, why not complain to the manufacturer which sell "development cards" and rely on "developper community" without helping them in return ?
  10. chwe liked a post in a topic by Larry Bank in RPi SenseHAT on Tinkerboard   
    I wrote some C code to talk to the sense hat from Armbian. The display works fine and so do the sensors:
     
    https://github.com/bitbank2/sense_hat_unchained
     
     
  11. jkljkl1197 liked a post in a topic by chwe in How do I use the camera on tinkerboard?   
    it's everything there to try it on your own..   
     
    I decided that I need a break from the tinker cam cause it's frustrating to get oop as a first boot message..  Since my buildmachine is only limited usable. I build on a old desktop machine which doesn't have a screen and everything is through ssh --> copying to my notebook prior to flashing it to SD-Card (wifi card is broken, and the stick which is attached to it performs very bad), I'm not that motivated to build as much images as possible to nail down the problem. And I'm not experienced enough to figure out the problems without a 'try and error' approach..  So any help and findings what might help is appreciated.. 
  12. chwe liked a post in a topic by JMCC in libdrm-rockchip install from Source failed   
    You're right. They are still using an old set of libs, with libmali r0p9 (Rockchip is using r0p14 now). I was hoping they changed it in their last release. I tested it, and saw lots of artifacts in webgl that don't happen when you use the more recent versions of the libs.
     
    In Armbian, we are implementing the most updated versions, and everything has worked so far very well, including drm, without that lib. However I have repackaged it from TinkerOS, and I'm attaching the deb to this post. But you must realize that if you install it in Armbian Stretch, you will not have all the other libraries necessary to make GPU acceleration work.
     
    My recommendation would be that you start from an Armbian Xenial default image, if your project can work on Xenial, and then follow the steps in the following guide (only the parts you need): https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/
     
    Then try to make your project work without libdrm-rockchip. If it doesn't , then install the deb and try.  I'm very interested in knowing the results, so I would appreciate if you shared them. That would help to the development, and we may include that lib in case it turns out to be useful.
     
    Thanks. 
     
    libdrm-rockchip1_2.4.74-2_armhf.deb
  13. chwe liked a post in a topic by sgjava in ArmbianIO API proposal   
    @chwe I don't remember why I removed this. I just added it back. Try again and it should register with Python now.
  14. chwe liked a post in a topic by Da Xue in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    @tkaiser Allwinner only certifies the H3 to operate at 1008MHz @1.2V and H5 to operate at 1008MHz @ 1.1V with DDR clocks up to 672MHz. Designs and software support for adjustable voltage and higher clock rates must be validated by the third party that chooses to implementing such features.  DVFS will not be supported in the Allwinner H3/H5 BSPs since the transition to AXP8036. I have seen some small boards with 16-bit DDR3 (1 DDR chip) clocked at 744MHz but they are almost guaranteed to have memory errors and video playback issues.
  15. chwe liked a post in a topic by JMCC in Pi-Factor power solution   
    Okay, I knew your board was missing something, but I couldn't point what it was. I think I finally got it:
     

     
    That makes it perfect! Don't you think so?
  16. chwe liked a post in a topic by 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-)  The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc.  (I wish it had 1GB of RAM but that's a different subject.)  I'd love to use these boards for a number of projects.
     
    As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board.  I also enabled the allowed clock changes to 1.2GHz for cpufreq.  All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v.
     
    I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v.  I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board!  I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board.
     
    So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board.  And now it works great!  VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems.
     
    Would anyone have an idea why Xunlong doesn't solder this part on the board by default?  They include all the other parts in this part of the power circuit, just not this MOSFET.  I was going to buy a few more of these boards, and I'd like to be able to clock them up.  Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...?
     
    Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis?  My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS).  By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds.
     
    Thank you!
     
  17. chwe liked a post in a topic by TonyMac32 in Pi-Factor power solution   
    I've done some load testing of my first prototype power "mezzanine" board (can't say "hat")    The voltage drop of powering the RPi touchscreen off of the GPIO while the tinker is on micro-USB is insane, I was reading 3.9 Volts on the USB ports when I ran minerd --benchmark.  I may have finally worn out the Micro-USB connector...
     
    This is a project for learning the ins and outs of kicad and get an idea of the capabilities of the PCB houses I have reasonably fast access to (Chinese ones unfortunately always get stuck in customs for a week or more on top of the normal shipping and fab times, so the cost savings is lost in time)  I have some more interesting things in mind, but I thought I'd start out (very) small.  The input is protected by the recommended ideal diode circuit from the RPi guys, stress testing didn't even make it warm.  If a better solution is needed, it can obviously be designed, but this is extremely cheap all things considered and that was part of the G&O for this project.
     
    By comparison, using this GPIO board to power everything resulted in a minimum 4.8 volts while also powering a USB 2.0 spinning disk HDD. (lower than I'd hoped, I'm going to make some adjustments to see if I can squeeze a bit more out once I get the redesigned version 2 back, I forgot about the temperature rise factor... )
     

     
    One of the issues goes back to our friends at RPi, the 5V pins are on the outside edge, so you have to go around the inner row to get to them.  This complicates moving big conductors around somewhat...
     
    The chip in the back is a SPI NOR for booting the Tinker (experimental, I threw it in there as an experiment and never actually performed the experiment...)  I'll probably wipe it from the board, perhaps leave an 8-pin SMT-adapter-sized pattern to the SPI for the adventurous.
    Power supply used here is the Odroid XU4 supply.  This initial run has no overvoltage or overcurrent protection.  And I need finer tipped soldering iron... 
     
    I'll GitHub this one after some cleaning and citation of sources, normal disclaimers for those who want to build one.  I will have moved one of the USB ports though since @chwe happily pointed out that Y-cables don't reach that far to get from the real ports to the power-only ones...  (oops)
     
    Boards successfully powered by this configuration (I don't / can't own one of everything... ):
    Tinker Board Le Potato NanoPi K2  (Already has a barrel jack, by the way, but you never know, maybe you want the bigger one)
  18. jkljkl1197 liked a post in a topic by chwe in RFC Tinker Board UART number   
    On the other side, people are frustrated when @Igor bricks some builds by pushing some stuff to apt.armbian.com  I don't know how many full time employees are working to maintain the tinkerOS and how experienced they are in maintaining such a system. Besides their AAEON Up boards (x86 architecture, from a different business unit), it's the first time that they dive into this market, and I think they perform not bad for a 'newbie'... In the long term, I think in it would save them a lot of time to stay with RKs upstream kernel with patches (as we do with armbian), cause RKs userspace stuff (e.g. gstreamer) evolves too and might be incompatible to their kernelfork in the future.
    But this is a nice example to show all the efforts which are needed to bring up a project like armbian. There aren't that much boardmakers which maintain their boards closer to upstream as armbian...  Btw. @JMCC, I appreciate your efforts in the whole hardware accelerated multimedia stuff. IMO because of that, the tinker is one of the few boards which can be suggested as a 'multimedia armbian board' (even when my personal interests in multimedia is minor -  the reason I own a tinker was because they didn't sell well here and were on discount for a long time..  40$ ~a year ago, now ~70$ ). 
     
    @TonyMac32 did you check, if there's a (easy) possibility  to get serial console silent from userspace (uboot and kernel, without recomplilation)? I've in mind that there's a silent mode which can be activated during compilation  (u-boot) but I never tested it. Reason: when people start to play with hats, it might be needed to keep it silent to avoid conflicts with the hats (even when I think that a silent console is a bad idea..  ). 
  19. chwe liked a post in a topic by JMCC in Rock64 Rockchip_dri driver missing   
    I don't have a Rock64 to test, but here are some clues that might help you to make it work:
     
    First, you need to make sure the kernel has the right drivers. I'm not familiar with the Ayufan kernel we use in Armbian as source, so I cannot help you with that.
     
    Second, you need to install the libs:
    wget https://github.com/rockchip-linux/rk-rootfs-build/blob/master/packages/armhf/libmali/libmali-rk-utgard-450-r7p0_1.6-1_armhf.deb sudo dpkg -i libmali-rk-utgard-450-r7p0_1.6-1_armhf.deb  
    Third, you need to fix the permissions. I think for mali 450 you can manage by adding to /etc/rc.local something like the following:
    chmod 666 /dev/mali* chmod 666 /dev/ump* Again, not sure since I cannot test.
     
    Fourth, install the armsoc driver. Rockchip's X server and driver are for Debian Stretch, but I compiled a version for Ubuntu Xenial. Provided that the steps above are OK:
    Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk Unzip it cd xserver-1.18-ubuntu sudo dpkg -i *.deb sudo apt -f install  
    Fifth (and last), backup /etc/X11/xorg.conf.d/01-armbian-defaults.conf, and edit like the following:
    Section "Device" Identifier "Mali-Fbdev" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Debug" "false" Option "DPMS" "false" Option "NoFlip" "true" Option "SWcursor" "true" #Option "InitFromFBDev" "false" EndSection Section "ServerLayout" Identifier "Default Layout" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "DRI" Mode 0666 EndSection Give it a try. You may need to add/modify many things, but this will give you a starting point.
  20. chwe liked a post in a topic by segv in Questions on Ayufan's Rock64 Images.   
    Thank you Igor: how stupid of me not to look in the commit messages and find that eth1 had simply been disabled in the DT.
    Thank you also Xalius for the DT overlay tip: it is neat to be able to patch the DT in the running kernel.
     
    For other users the following command re-enables eth1 at run time:
    sudo enable_dtoverlay eth1 ethernet@ff550000 okay
  21. chwe liked a post in a topic by MickMake in The mmBoard   
    Yeah, I was going to go with 10GbE, but it would have set the price too high. :-)
     
     
    Yup, different memory sizes are available. I'll even throw in a free stick of BluTak - https://en.wikipedia.org/wiki/Blu_Tack.
     
     
     
    Ahem... Well, around 100,000 Argentinian Pesos. It sounds like a lot, but it really isn't. The exchange rate is pretty good... or was.
     
     
    You gotta love it.
     
     
  22. chwe liked a post in a topic by guidol in Pi-factor cases   
    2 years ago I ordered a blue, red and yellow of these LEGO-cases along with (at this time) 3 new RPi3.
    But if you want to change the board its hard to realese it out of the case and some part can break.
    For underclocked RPis (and children) its a nice case.

  23. Igor liked a post in a topic by chwe in how to upgrade?   
    https://asciinema.org/a/Goj9aUPvgpGk6YCx97Lqj3XwV
     
     
  24. Igor liked a post in a topic by chwe in how to upgrade?   
    https://asciinema.org/a/Goj9aUPvgpGk6YCx97Lqj3XwV