Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Posts posted by tkaiser

  1. http://linux-sunxi.org/Banana_Pi#Powering_the_board

     

    The Banana Pi has two MicroUSB connectors one being used for power-in and the other is USB-OTG (also suitable to power the board since the AXP209 PMU can be feed from power-in, USB-OTG and LiPo battery: you could also solder a cable to the battery solder pads to power the board reliable but a bit weird ;-) )

     

    Powering disk and board separately is always better. And I also had good experiences using 24V (in fact 27V from a quality PSU) to power a bunch of RPi over PoE with simple step-down converters on the other side of the Ethernet cable providing 5.1V to the boards.

  2. My understanding was that the supply would only provide what the device demands in terms of the current.

     

    Correct. But if your device demands more than 1.8A then MicroUSB is the wrong connector. And since many/most USB cables lead to voltage drops an USB connector to power the board reliably is always the wrong connector. The hardware vendors using this connector know this but they do not care since it's not their but the customer's problem and they try to be attractive for RPi users when choosing the same (crappy) connector to power their boards since users think they can re-use the PSU they used with RPi or any crappy cell phone charger.

     

    The usual story with this MicroUSB connector:

     

    User uses 5V/2A PSU as by the requirements and experiences random shutdowns in load situation or when he provokes peak current situations (connecting mouse/keyboard to USB, spinning up a connected hard disk). He asks somewhere in a forum and other users who had the same problem before answer: "Hey, now I use 5V/4A and problems are gone", "Me too, with my new 5V/3.5A PSU everything's perfect".

     

    In reality the amperage doesn't made the difference but the new PSU had a directly connected cable which prevented the voltage drops. That's all. You won't be able to let an A20 based device demand more than 600mA when running at 100% on all CPU cores while being overclocked. Same applies to 2.5" HDDs (expect peak power consumption when spinning up!). On nearly every board it's always voltage drops that are the problem. And they happen only under 'full load' situations (compare with the graphs in the aforementioned link).

     

    I know 3 exceptions:

     

    - Lamobo R1: There the on-board switch IC and Wi-Fi and the different power scheme (powering the hard disk through the PSU instead of directly connecting pwr-in with SATA-power) leads to situations where the R1 exceeds the 1.8A

     

    - Lemon Pi and Roseapple Pi (use the same reference design): They aren't attractive at all due to their S500 SoC. But these two boards feature a MicroUSB connector for pwr-in and also 2 USB 2.0 type A ports (each one providing "up to" 500mA for devices) and 1 USB 3.0 port providing "up to" 900mA. In the schematics it's written that you will need a PSU rated with 2.4A or above if you plan to use power hungry disks on the USB connectors. While they use a pwr-in connector that is rated 1.8A max. -- broken by design

  3. to get decent transfer rates between the Banana Pi & my desktop PC, I'll need to connect everything to a GbE switch.

     

    Devices exist that are able to run OpenWRT/DD-WRT and aren't that expensive, eg this one: https://wiki.openwrt.org/toh/tp-link/tl-wdr4300

     

    In case you've an old 3.5" PATA disk enclosure lying aroung you could use the PSU from this device (dual voltage) and provide power to the router and Banana Pi simultaneously. A 12V PSU and step-down converters will also do the job.

  4. MicroUSB connecter which will provide 5V3A

     

    Nope. "MicroUSB connector" is rated 1.8A max. -- the contacts being too tiny prevent you from providing anything above 2.0A and while you're doing this you're already violating specs and the connector gets hot. Even worse: Many/most USB cables are crappy and lead to voltage drops.

     

    Never ever buy a device with peak consumption exceeding 8 W (applies to many SBC with a connected 2.5" disk) and that wants to be powered through MicroUSB. MicroUSB as "DC in" solution has been made with cell phones in mind where neither voltage drops do any harm except longer charging times nor the current limitation (most people won't even notice when their phone takes twice as much time to recharge due to crappy cables/connector)

  5. it is LAN-only, some people claim that they got it to work in VPNs, however maybe they are confused while using the VPN service in their home network. I might make the multimedia files available in the VPN through HTTP

     

    Protocols relying on link local addresses and multicast shouldn't work over VPN connections by design.

     

    I recently searched for a way to announce 5 camera live streams and a bunch of videos encoded before via UPnP and ended up with something called 'xupnpd' (runs on ARMv7/A20). I use the following code to provide one playlist containing the 5 livestreams:

    	PlayList=/usr/local/xupnpd/src/playlists/playlist.m3u
    	StartPort=8551
    	StreamFolder="${StreamBase}/$(date "+%Y-%m-%d")"
    	
    	echo -e "#EXTM3U name=\"Live\"" >"${PlayList}"
    	sleep 1
    	
    	grep -v "#" /var/run/pispy.lst | while read ; do
    		set $REPLY
    		Hostname=$1
    		Address=$2
    		
    		# create playlist entry
    		echo -e "#EXTINF:0 type=h264 ,${Hostname}\nrtsp://${MyAddress}:${StartPort}/${Hostname}" >>"${PlayList}"
    		
    		# create stream file
    		if [ ! -d "${StreamFolder}" ]; then
    			mkdir -p -m2777 "${StreamFolder}"
    		fi
    		StreamName="${TimeNow}-${Hostname}.h264"
    		StreamFile="${StreamFolder}/${StreamName}"
    		
    		/usr/local/pispy/record-and-transcode-stream.sh ${Hostname} ${Address} "${StreamFile}" ${StartPort} &
    		
    		StartPort=$(( ${StartPort} + 1 ))
    	done
    

    All previous recordings are converted to .mp4 files and then I let another script also create playlist for all these files. The skeleton looks like this (just to give you an idea how the .m3u files should look like since this took me some time):

    	PlayList="${TempDir}/record-${i}.m3u"
    	((i++))
    	# check whether it's today
    	Today="$(date "+%Y-%m-%d")"
    	if [ "X$FolderName" = "X${Today}" ]; then
    		echo -e "#EXTM3U name=\"Aufzeichnungen Heute\"" >"${PlayList}"
    	else
    		echo -e "#EXTM3U name=\"Aufzeichnungen ${FolderName}\"" >"${PlayList}"
    	fi
    	find "${StreamBase}/${FolderName}" -name "*.mp4" | sort | while read ; do
                ...
                echo -e "#EXTINF:0 event=reload ,${ClipName}\nfile://${StreamBase}/${FolderName}/${FileName}" >>"${PlayList}"
    	done
    

    Maybe you can use xupnpd as some sort of proxy providing SSDP multicast announcements at the other side of the VPN connection?

  6. LOL. They still ship with the moronic display config with an imaginary LCD device being the 'master display' and using 1024x600 resolution upscaled to 1920x1080 on HDMI: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=22515&pid=90542

     

    Forum users showed them how this crap can be fixed but they refuse to implement the fix. They simply don't give a sh*t about user's needs ("Hey, who needs working USB3?"). Or they're simply not able to fix the issues with the 'SDK' they got from Actions Semi. 

  7. Actually flashing any S500 device is USB 2.0 only. They use the Mirco-USB connectors containing the USB 2.0 part solely. This is clear since in the S500's manual it's written that only the USB 2.0 controller is OTG capable. In the meantime they clarified this also in their wiki and the so called 'user manual'. I tried to get informations so many times from them and they either don't answer or don't care about correctness.

     

    Last example: Tido asking why /dev/usb will be removed every time the last USB peripheral gets disconnected. And they give him a totally unrelated answer: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=22797&pid=90545

     

    Same again here: One person asking for the temperature operation range doesn't get the right answer ("Sorry, this is a tablet SoC and there isn't something like this defined in its datasheet. You can not use it") but random nonsense instead. In the specs the thermal range is specified as "TBD" and both SoC as well as PMIC get way to hot to use this SoC in any commercial application.

     

    I asked them 8 questions about an upcoming baseboard revision. And got 0 responses so far.

     

    LeMaker's only asset was the community around Banana Pi. But this doesn't exist any longer. People trying to get support for Banana Pi are lost in the meantime.

     

    And I doubt you get the idea how "product design" works with cheap SBCs? Almost everything the SBC is able to do depends on the SoC's capabilities. And when you choose a SoC that has neither PCIe nor SATA nor GBit Ethernet and you design the board in a way that the only USB3 port isn't useable... then you have a board that sux.

     

    With the original Banana Pi everything was different. Its SoC, the A20, was used in other SBCs already and features both SATA as well as GBit Ethernet, the linux-sunxi community existed already, all LeMaker had to do was collecting already available informations and software and try to build a community around the board. That worked somewhat. Then they were greedy and applied for the Banana Pi trademarks and in the end they had to give up with Banana Pi/Pro (AFAIK they still sell both and at least here in Germany you got many SinoVoip products only through LeMaker resellers and just recently also through SinoVoip's agent)

     

    But this will change in the future. And now with Actions Semi they are in a completely different position. The S500 is clearly faster than A20 but lacks many features. Due to the brain-dead Micro-USB connector they prevented anyone from using USB3.0. Regarding know-how and software support for the board everything is completely different. Every question Actions Semi isn't able to answer them won't get answered. And regarding the state of the so called 'SDK' it's a real mess. Software gets fragmented right now, insanely dumb development style, therefore I doubt we will see a newer kernel version anytime soon or at all. No newer kernel means no fixes and no drivers useable that exists only for more recent kernel versions (no driver --> no hardware useable that needs this driver). The Guitar tries to be a modular SoM/SBC concept but given the software state it's an Android only toy with very limited use.

  8. One final note regarding software support for the Guitar (or any other device using the S500 SoC, currently Lemon/Roseapple Pi). I tried to explain why the S500's kernel version stalls at 3.10.37 (several thousand fixes behind the current 3.10.93 LTS kernel), what's wrong with the so called 'SDK' Actions Semi recently released and why the situation won't change that fast unless at Actions Semi they would really want to become an 'open source community member':

     

    http://forum.linux-xapple.org/t/share-ubuntu-14-04-lts-image/130/13?u=tkaiser

    http://forum.linux-xapple.org/t/relationship-between-xapple-rose/129/4?u=tkaiser

     

    In the meantime I also adjusted RPi-Monitor templates for S500/ATC2603. Works with the Guitar as well but consumption read-out is still WiP: http://wiki.linux-xapple.org/w/index.php/RPi-Monitor#Work_in_progress

  9. Regarding I2S: I would prefer a solution that works without an annoying fan (byebye S500) and is definitely known to work: http://odroid.com/dokuwiki/doku.php?id=en:c1_hifi_shield(the C1+ is also faster and gets way better support from its manufacturer!)

     

    Given the fact that LeMaker shipped their first OS image with a totally wrong display config (native 1024x600 pixel, upscaled to 1920x1080 pixel, again upscaled to 2560x1600 pixel on my display) and that they didn't manage to provide a fix for this over weeks (a forum user just did copy&paste from another .dts file in a trial&error style and solved the problem eventually) I wouldn't expect that you can get any support in case you're running in device-tree related problems from LeMaker (and I don't know how to reach Actions Semi directly -- LeMaker likes to play the intermediary role).

  10. Would any specific kernel/dtb changes be needed to make a I2S DAC board to function on the Lemaker Guitar ?

     

    No idea. According to their Wiki I2S is available at the 40 pin GPIO header. But according to their wiki the Guitar is able to output 4096*2048@30HZ through HDMI and drive LCD displays also with 4096*2048 pixel (both wrong. The S500's maximum resolution is 1920x1080 on both HDMI and LCD). You can't trust the informations there as usual. It's just copy&paste from somewhere else and noone of the responsible people gives a sh*t about correct specifications/informations.

  11. Since you are talking about using mainline kernel and all the posts above deal with kernel 3.4 it was a rather bad idea to hijack especially this thread!

     

    [PROBLEM]:

    U-BOOT does not load .dtb file for Banana Pi M1 Plus, but it loads file for Banana Pi M1 (without Plus)

     

    The following is similar inelegant as your approach but works the same way:

    cat /boot/dtb/sun7i-a20-bananapi-m1-plus.dtb >/boot/dtb/sun7i-a20-bananapi-m1.dtb
    

    (you hardcoded a different path to read the .dtb from into /boot/boot.scr, I simply exchanged the contents of the file being read by default :) )

  12. All Banana Pi models have at least solder pads to connect a battery (this is one of the many advantages of using a tablet SoC/PMU -- running on LiPo battery and also charging are supported 'by design'). And yes, I also quoted these comments from the driver's sources many times in the past. The funny thing is: the very same people that've written these comments also use the values they extract to implement thermal throttling in mainline kernel.

     

    BTW: And to raise confusion again: the A13 SoC's name sounds like A10's sibling but it's sun5i and behaves like the A20 regarding SoC temp. To sum it up: Forget about SoC temp on these older SoCs and use the PMU's instead (at least the AXP209 contains overheat protection and shuts the board down immediately when an internal treshold is reached -- don't know how to influence this)

  13. As far as I read linked topic, this should be correct for current kernel.

     

    You should be aware that while there is a thermal sensor inside the A20 SoC it's known to be not that accurate. In mainline kernel which exposes the A20's thermal sensor also using sysfs at a 'standard location' things went somewhat wrong: https://groups.google.com/d/msg/linux-sunxi/duvqtZbfqoI/15K45TKj7iwJ

     

    Simple conclusion: You should better not trust in the values kernel modules try to extract from the thermal sensor inside the A20's touchpad controller. Better rely on the PMU's temperature. This is more important since it scales also linearly with load but will also increase/decrease based on the amount of power the 'whole system' needs (bus powered USB peripherals for example will use extra power which increase the PMU's temperature)

  14. my main labomo issue (despite bridging & upnp) is BW is cpu limited (too many IRQs) so my 500Mbits/s internet is limited to 360 Mbits/s

     

    AFAIK no one ever achieved better results. I don't know the reason and simply gave up on that board (or to be more precise on any SinoVoip product).

     

    You might find some insights in one of the threads here where we discussed the Lamobo's bad performance. Or maybe at bananapi.com. There in the worst forum ever a user supplied an OpenWRT build and claims he solved the performance issues. I also gave up since my questions weren't answered or understood (you find so many misleading stuff regarding R1 on the net -- some people confuse switching performance between external Ethernet ports with routing speed -- that it's not worth to believe in what others say. And the R1 I had here at my place has been delivered to a customer and I surely will never buy one again :-) )

  15. Using dtc will be totally sufficient ('apt-get install device-tree-compiler' if it's not installed by default). And unless you also tinker around with u-boot you have to take care that the .dtb file is named absolutely identical afterwards since otherwise it won't be loaded.

     

    But since the official .dts contains includes you have to decompile the .dtb currently in use and carefully apply all relevant changes between those two files:

     

    https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts

    https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20-pcduino3.dts

     

    EDIT: Posted too late ;-)

  16. I assume you already had a look at the FAQ? http://www.armbian.com/documentation/

     

    Then regarding your pcDuino3 (not nano): For kernel 3.4 you should exchange the so called .fex file (script.bin) and with mainline kernel the .dts/.dtb stuff should be exchanged: Here you find the links:

     

    http://linux-sunxi.org/LinkSprite_pcDuino_V3

    http://linux-sunxi.org/LinkSprite_pcDuino3_Nano(Armbian uses not 'the official' fex file from LinkSprite but a better version taking care of some stuff -- mostly copy&paste from other A20 based board's fex stuff)

     

    Regarding removing the desktop stuff have a look what Igor's install_desktop function installs: https://github.com/igorpecovnik/lib/blob/second/desktop.sh

     

    Do an 'sudo apt-get remove' for all those packets followed by

    sudo apt-get -y autoremove
    sudo apt-get clean
    

    And regarding auto login: http://forum.armbian.com/index.php/topic/208-ubuntu-xfce-auto-login-as-root/

  17. Sorry, but the Guitar is dead. Way too expensive, high performance only possible when combined with an annoying fan and weird design decisions. Since every standard Micro-USB3-OTG cable does NOT work together with the Guitar they need to bundle such a cable with their baseboard otherwise the advertised feature "USB 3" isn't available.

     

    It's moronic to inform customers that they have to customize their cables to use the only interesting feature for a board in this price range: USB3. Without useable USB3 both storage and network performance are way too slow.

     

    Even if you're not interested in storage/network performance the Guitar is a bad choice: You have to configure the board to either run slow or you get in trouble due to thermal issues. Due to the brain-dead board layout you can not use GPIO-Add-Ons (Raspberry Pi HATs) and a fan at the same time. So it will be either slow or with limited functionality.

     

    Add the software problems (no mainline kernel support, just a horribly outdated kernel 3.10.37 lacking essential features) and you have to come to the conclusion that the Guitar isn't worth the price (the reseller's prices here in Germany are rather high: Baseboard and Coreboard add up to over 90,-€ including shipping and ordering directly from lenovator.com with shipping costs of $33 doesn't make a difference).

     

    For less than that I get an ODROID-XU4 (8 CPU cores and not just 4, 2 GByte RAM instead of 1, 2 useable USB3 ports instead of 0, GBit Ethernet instead of Fast Ethernet, experimental mainline kernel support instead of an outdated 3.10.37 kernel being 2450 fixes behind 3.10.92) and for the same price I get two comparable ODROID-C1+ which shares some limitations (kernel 3.10 and no USB3) but is way more attractive due to high performance without thermal issues and GBit Ethernet.

  18. the one you are linking to. 

     

    I used the cnx-software.com link for a reason because there is not one but three similar boards mentioned (one of them being canceled in the meantime):

     

    WiTi Board: https://mqmaker.com(headed by Benn Huang, co-founder of CubieTech)

    Turris Omnia: https://omnia.turris.cz/en/(no idea who they are)

     

    Unlike Lamobo R1's manufacturer the people behind WiTi board released their stuff very early: http://ftp.mqmaker.com/WiTi/

     

    And in the comments on cnx there are other similar MT7621A based designs mentioned: http://www.cnx-software.com/2015/08/12/witi-openwrt-router-board-features-6-ethernet-ports-dual-band-wifi-sata-and-usb-3-0-ports-crowdfunding/#comment-435523

     

    If I would need a board with a few GBit ports and SATA I would never ever choose the R1 again :-)

     

    Benn already posted performance numbers (and not the usual SBC benchmark stuff where everything is measured wrong but reasonable test setups testing storage and network also individually): https://mqmaker.com/tutorials/making-your-own-nas-with-witi-board/-- looks promising to me. If there will be a board variant with 512 MB or even 1 GB this would be my favourite. 

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines