bzfrp reacted to MitchD in Buildroot realtime image for nanopi neo
I'm not sure if anyone is interested in a very small distro without gcc, but I spent some time the last week using buildroot and armbian's source files to create a 3.4.112-rt image for the nanopi neo. It is going to be part of a realtime audio project (think synth or guitar pedal) that I'm working on and it demands a quick boot, among other things.
There is also a mainline version, but it doesn't have all the fixings you folks like, so I don't know if you'd want to use that.
You can find the build scripts and config files on my github. I'll be posting the legacy image in a zip file tonight, once I verify everything is reproducible.
I would like to thank the Armbian developers for all their time and energy doing what they do. Their code and guides have helped me understand how one would even attempt something like this, and I'm very grateful. If you ever use my image, please donate to the Armbian community.
The screenshot is proof that the system works, and how much ram it uses while forwarding a puredata session over X-forwarding.
I'm open to any questions. Thanks.
bzfrp reacted to Larry Bank in What are you using your Orange Pi Zero for?
I've been experimenting with the OP0 for use in a portable gaming device with an inexpensive SPI LCD display. I wrote all of the game emulator code, so it's very efficient between reading input and sending the image to the LCD (without fbtft).
bzfrp reacted to tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA
'1080p video' is resolution but doesn't tell anthing regarding bitrates (depends on encoding/codec used). So you have to check how high bitrate requirements of your media files are. Please note: most people confuse codecs with file/container formats. If you have files lying around with names ending on .mp4 that still doesn't tell anything: https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams
The good news: bitrate requirements for most media formats are rather low so even Fast Ethernet should suffice (since this stuff is meant for streaming and the usual encoders are configured to not exceed a specific bitrate anyway -- in case 'the scene' needs higher bitrates than allowed the encoder partially decreases image quality to remain below the bitrate treshold).
Fast Ethernet means 8 MB/s at least. With current cpufreq settings in Armbian images actual values might be lower since cpufreq might remain at the lower 240 MHz most of the time. Switching to performance governor might help: http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor
But even the 5 MB/s reported by @jimandroidpc should be sufficient for most media files (please remember that there are many Android TV boxes with only Fast Ethernet around and the bitrates that work reliably over crappy 2.4GHz Wi-Fi have to be even lower).
I won't comment on RAID used with SBC since I did it too often already. TL;DR: RAID has nothing to do with 'data safety', this is only about availability (business continuity) and people constantly fool themselves with RAID (if you're interested in my opinions a web search for 'tkaiser crap raid availability' or something like that should help).
Again: I really hope that Xunlong already prepared a new board with Gigabit Ethernet and Zero form factor since with current Zero the NAS Expansion board seems somewhat strange (the JSM578 is capable of SAT and therefore also SMART, supports TRIM/UNMAP and also UAS which is nice since Allwinner SoCs can make use of UAS even with USB 2.0 when running mainline kernel. Normally you find this feature only on USB3 capable devices). But JMS578's potential is wasted on a board with only Fast Ethernet and crappy Wi-Fi.
bzfrp reacted to tkaiser in Tips on speeding up boot process M1/Neo
To sum it up (I use NEO as example since there it's more obvious)
NEO is supposed to start with just 480 MHz clockspeed (that setting got lost before 5.20 update but will be re-applied later). Reason: Limit max consumption while booting to 2W. Since default cpufreq governor in sun8i kernel is userspace this means that NEO will run with only 480 MHz until the init system starts cpufrequtils. Armbian's default u-boot settings are meant for users that have to solve problems from time to time, so we activate some stuff there to interact with u-boot and also have a short delay to stop auto-boot Armbian normally starts a whole init system that mike some time to finish until the distro's own mechanism to autostart things kicks in (be it a startup item or a call from /etc/rc.local) To address 1) it's just setting a higher clockspeed. ATM I'm just too lazy to look whether it's ok to set 'CONFIG_SYS_CLK_FREQ=1200000000' there since this would also require u-boot to switch to the higher VDD_CPUX voltage on NanoPis (if the voltage remains at 1.1V then freezes/crashes might occur while booting -- we had that back with OPi One in February when I f*cked up settings for some time). In case no voltage switching happens in u-boot relying on the default 1008 MHz as we do now on all other H3 devices might already be wrong (@Zador?)
For 2) it's just disabling stuff in u-boot so that no time is wasted there waiting Ethernet, USB and keystrokes.
Examples for avoiding the usual init system are (NÂ°3 above) are USBootPi or lima-memtester (see there the 'Compiling everything from sources' -- this is buildroot there and not Armbian at all).
Anyway: you need at least a serial console and a lot of knowledge (also how to avoid destroying your tweaks by the next regular Armbian updates).
So in case you find boot times annoying especially with NEO then the more simple variant would be to
use the Armbian image for M1 replace /boot/script.bin with /boot/bin/nanopineo.bin (not just adjust the link but really overwrite it, doing it this way will ensure that next Armbian updates leave script.bin alone) Adjust /etc/hostname Booting with 480 MHz vs. 1008 MHz will already make a huge difference.
bzfrp reacted to gahabana in Kernel dev (4.9) - which board runs reasonably well - Orange PI One , NanoPI Neo or something else ?
hi all, @bzrfp,
finally got last weekend NanoPi NEO.
Went to my Armbian directory, fired it up, said i'd like Ubuntu Xenial with devt kernel console and 20 mins later i had the image. I have customized image build for my odroid-c2 (added squeezelite package to lib.config file under userpatches directory and i added roon endpoint install script (slightly modified)) to avoid having to type couple of commands into produced image once its made.
So my Armbian build process is really plain Armbian build plus install of squeezelite (for LMS server) and Roon Endpoint.
Anyhow, burnt the image, tested it - rebooted, put in a case,connected usb dac and ethernet again and it's been working for a week with 0 hicups. Both as squeezelite player and roon endpoint. boots in less then 20 seconds ... but as i said did it only twice week ago
I do have CPU cooler that i ordered with NanoPI NEO ... the ONLY change i made was put CPU in performance mode running at 1.2 GHz. .... worked well with less then 1Ghz as well ... Roon needs no CPU really (i can only test up to 192khz/24bit with my Benchmark DAC2) and squeezelite has no trouble with even converting DSD64 stream to PCM 192khz ... CPU utilisation in one of the cores jumps to 100% for a while but there are no dropouts.
I do have Intona USB Isolator connected after it (its about 10 times bigger then NanoPI itself but i hear no major difference (nothing bad) compared to OdroidC2 nor the PC i used to have before as endpoint.
for 15$ doesnt get much better
Thanks to Armbian guys this is really easy !!!!!!!