gounthar

Someone sends me one I'll look at the prospects, but a proposal for support needs to be under the board bringup thread

Today I did try my very best... Opened the R69 (without breaking anything), solder the TTL-Pins, connecting USB-TTL -
BUT when I power on with the u-boot button pressed I didnt get any output to disable the u-boot boot-sequence
(normally counting 3.2.1 on other boards and you have to press a key)
 
So I can - today - only deliver the boot-log from android on the R69 and two find commands for *.bin and *.fex as android-root on the filesystem:
 
 

I did get my R69 today (my birthday) - but did buy it myself
I also got a reboot problem with a old 8GB Samsung Class 4 uSD. It doesnt boot after filesystem-resizing (and after reconnect power),
but with a 16GB Sandisk Ultra Class 10 it does boot after resizing and power reconnecting
 
login as: root root@192.168.6.151's password: ____ _ _ ____ __ ___ / ___| _ _ _ ____ _____| | | | _ \ / /_ / _ \ \___ \| | | | '_ \ \ / / _ \ | | | |_) | '_ \ (_) | ___) | |_| | | | \ V / __/ | | | _ <| (_) \__, | |____/ \__,_|_| |_|\_/ \___|_|_| |_| \_\\___/ /_/ Welcome to ARMBIAN 5.31 stable Ubuntu 16.04.3 LTS 3.4.113-sun8i System load: 0.23 0.26 0.12 Up time: 3 min Memory usage: 4 % of 1000MB IP: 192.168.6.151 CPU temp: 69°C Usage of /: 9% of 15G [ General system configuration: armbian-config ] Last login: Thu Oct 19 12:41:47 2017 from 192.168.6.17 root@beelinkx2:~# for the ASCII-Logo I changed the file /etc/update-motd.d/more 10-header
first apt update & upgrade is finsihed

used for my display (1280x1024)  h3disp -m33 
 
 
dmesg.txt

La Frite will be avalaible on november 2018. Now you can back it on kickstarter web page.  specs.; https://libre.computer/products/boards/aml-s805x-ac/ This is my proposal to support.
Best regards

Injection molded housing: cheap as hell when you produce enough
Aluminium/metal housing: not that cheap
 
As a premium tv box SoC, you either make a SoC which has high decoding capabilities with low heat generation or you force the tv-box makers that they do it properly (means higher housing costs due to metal cases)..  IMO there's a market for such devices either implemented in the TV or as a standalone box in addition. 
 
For the buy as cheap as possible fraction, you're right they buy by the bigger the better.. But as on other fields, there's a 'premium sector' where people care about things work properly and things get updated for a longer therm.. The only reason I would ever buy an Iphone again is the fact that I get a phone which is updated at least for the next 2 to 3 years... If you don't want to be a premium SoC supplier, fine cheat your customers sell it to every shitty TV-Box maker which doesn't give a fuck about updates and make your bucks there.. 
 
I guess, and that's just a guess that also their closed source SoCs benefit from the expertise they have now inside the company how to do it properly.. They might or might not cheat you with the closed source ones (I've no clue). But at least their in-house knowledge is grown. Google may switch to fuchsia to solve this problem with the shitty 'phone get's no update' situation or make it harder to install the google app store, e.g only if the SoC and the installed kernel fulfills some requirements. And google showed it on other fields that they can be harsh when they decide that something has to change (e.g Symantec in case of https). Mess up with google is for sure not fun for an SoC maker which is focused on android devices and I think google will use this power more and more to solve some of the issues they have. 
People start to care when they realize that their dick pic collection isn't save anymore cause there's a security hole which makes your data accessible for others [^1]...  
It's clear to me that the average user doesn't care what works behind the scenes/ opensourceness (as a 'windows for my daily tasks' -user, I'm also not part of the 'Stallman Church'). But more and more people are concerned about their data and how save they are... Solutions like home cloud, own cloud (whatever cloud which is not hosted by google or dropbox ) may get more attention.
Premium users may not pay attention to 'stupid specs' as long as the thing works the way work as they expect but they care about other things. Otherwise nobody would buy an macbook pro anymore cause from specs the xiaomi mi pro notebook throws every macbook in the bin, except display resolution (16gb ram, Samsung SSD + second m2 slot, i7-8550U and NVIDIA GeForce MX150 2GB for ~1000$) and it also looks 'somehow similar': 
 
But your apple macbook pro does the things you want and you don't care about maximum performance as long as it performs well on OSX. From a homecloud/nas/tv-box thingie in the higher price range you expect that it performs well for tv streaming, a little bit of BS gaming and that your dick pics are save. The easiest way to achieve this is by don't have your box open to the internet (which makes it shitty for a streaming box with integrated cloud thingie) or you have a your code peer reviewed by others who care about security... And I think the cheapest way to peer review your kernel code is to have it mainlined.  You need developers which code properly (higher costs) so that your PRs are accepted by the kernel maintainers but you get a peer review for free (lowers costs).
In the science world where I'm involved you've to possibilities to get your results published. You can either pay a fee to the journal so that they do the peer review process for you (normally ~2000-3000$ per article) or they do it for free but then every reader has to pay a fee to read your article (and those fees are horrible high around 5-10$ for read once or 50$ to get a pdf)..  Or you publish it in a low reputation publication where nobody will notice your results... Free open access journals with a good reputation barely exists (and mostly they're part of a series where you have to pay for all their other journals)... 
 
 
[^1]:
 
 
Edit: Maybe we should rename the topic again, moving it to General chit chat? Cause It's hijacked again for a lot of other stuff...  

Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956 (there you can also read what happened then in detail to get more control over clockspeeds on C2)
 
If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother?
 
Since I mentioned 'use case' and Raspberry Pi 3:
If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)  

OK, after some research I managed to find and configure a USB video grabber for my OrangePi PC Plus.
 
I'm building a audio center for my car using OrangePi. And I decided to install a cheap reversing camera from ebay in my car, which supplies composite analog video output.
I want to display the reversing cam stream on also on my OPi audio center display, so I needed an analog video grabber.
 
I have ordered exactly this one from ebay:
EasyCap DC60 USB Video Capture Card Adapter with ChipSet UTV 007 for Win 7 8 10
 
It's very important to let it have UTV 007 chipset surely,  attention, there are many copies with different chipsets. What I read other chipsets won't work.
I installed the driver from this link:
usbtv
 
After driver installation, you should see something like this:
# lsusb Bus 003 Device 005: ID 1b71:3002 Fushicai USBTV007 Video Grabber [EasyCAP] And check if the device could be used as a capture device:
# v4l2-ctl --all Driver Info (not using libv4l2): Driver name : usbtv Card type : usbtv Bus info : usb-sunxi-ehci-1.6 Driver version: 3.4.113 Capabilities : 0x05000001 Video Capture Read/Write Streaming Priority: 2 Video input : 0 (Composite: ok) Video Standard = 0x0000f900 PAL-M/60 NTSC-M/M-JP/443/M-KR Format Video Capture: Width/Height : 720/480 Pixel Format : 'YUYV' Field : Interlaced Bytes per Line : 1440 Size Image : 691200 Colorspace : SMPTE 170M Transfer Function : Default YCbCr Encoding : Default Quantization : Default  
This seems very good.
After that using mplayer I can see the captured video stream perfectly on my HDMI display with 800x480 resolution. 
You need to supply the proper options for mplayer. I wanted to see the stream on the framebuffer, since I don't use X window. This command works for me:
mplayer tv:// -tv driver=v4l2:norm=PAL-M:width=720:height=480:outfmt=yuy2:device=/dev/video0:input=0 -vf flip -vf expand=800:480:40:0 -vo fbdev:/dev/fb0 Change the video filter -vf options (flip, expand) according to your display resolution and needs (if needed at all).
The stream is playing perfectly, without any single frame dropped.
 
There is one important thing. Always connect the USB grabber to the OrangePi using a USB hub! The device is taking 330 mA which is too much for the OPi, without USB hub the OPi USB supply voltage drops down to 4.3 V. 
I'm planning to order and try this cable also: Delock Cable USB 3.0 type A male + USB type A male > USB 3.0 type A female, I hope with this one I can just supply an external 5V DC power to the dongle, without using a hub.
 

As a result of all the work that Armbian developers put into the upgrade to kernel 4.14 for the XU4 board family, now we can enjoy many new features. One of them is the access to the SoC video encoding capabilities.
 
Emby Media Server can take advantage of the Exynos 5422 MFC video engine for transcoding. That means lower CPU usage, lower temperatures, and the possibility of encoding in real time higher resolutions or more simultaneous streams. In my tests, I've been able to transcode one HEVC 1080p and one 480p at the same time, or five 480p (though it will depend on the bitrate of the source material).
 
However, the ffmpeg version shipped with official Emby is quite unstable when using this feature. For that reason, I compiled a better and more stable version from @memeka's repo. I've been using it for over a month without a single crash.
 
So this is a step-by step guide on how to make everything work:
 
0. [PREREQUISITE]: You must be running an Armbian Strech XU4 "Next" image, like the one you can download here.
 
>> DOWNLOAD the emby and ffmpeg packages from this link << Install them (Note: this will install Emby Server version 3.5.3, which is the last at the writing of this tutorial. It has been tested to work with this version, and may or may not work with any other): $ tar xvf emby-server-stretch-xu4_1.0.tar.xz $ sudo dpkg -i ffmpeg/*.deb $ sudo dpkg -i emby-server/*.deb $ sudo apt -f install  
Hold the ffmpeg packages, so they don't get upgraded:  
$ sudo apt-mark hold ffmpeg-doc ffmpeg libavcodec-dev libavcodec-extra libavdevice-dev libavfilter-dev libavfilter-extra libavformat-dev libavresample-dev libavutil-dev libmysofa-dev libmysofa-utils libmysofa0 libpostproc-dev libswresample-dev libswscale-dev  
Add the user "emby" to the video group, so it can have access to the transcoding engine: $ sudo usermod -aG video emby  
Modify the emby executable, to use our custom ffmpeg (Note: you will need to repeat this step every time you update the emby deb package): $ sudo nano /opt/emby-server/bin/emby-server # Change the following line: ffmpeg $APP_DIR/bin/ffmpeg \ # to: ffmpeg /usr/bin/ffmpeg \  
Restart the service:
$ sudo service emby-server restart  
Now, you can open the web browser, point to your Emby server (e.g. http://odroidxu4.local:8096), and configure it as described in the official tutorial (https://github.com/MediaBrowser/Wiki/wiki/Installation).
For last, you need to enable Hardware video transcoding in the web interface. The option is under the "Transcoding" submenu. Don't forget to click on "Save" when you are done:
 
 

 
And that's it!
 
As an additional tip, I recommend disabling UPnP in Emby, because it causes the program to crash frequently when enabled (this is just a general recommendation, it has nothing to do with hardware encoding).
 
Enjoy! And please, share your experiences and comments here.

Sounds good...  When/If pics happen - top/bottom of the board, thermal solution, take a close look at WiFi (should be a system on module, if you can note the vendor/model there), and mass storage... also look for UART pads, as this is key - if you can get into uBoot, that's a good thing...
 
I suspect that whatever they're doing, it's going to be super cost optimized... at the sub-$30USD price, including an IR Remote, HDMI cable, AC adapter, and of course the shipping box -- Sunveil must have done lot of work to reduce any additional BOM costs to keep some profit on the product.
 
In past experience with AllWinnner Android boxes, ADB is there, and fairly open, at least on Android 4.x - this one runs Android 7* (Nougat) so all bets are off - just note that there might be some security items with the BSP that you can take advantage of to get root for spelunking of the OS in general... First shot would be -- If Google's PlayStore is enabled within the stock Android on that box, one might consider getting "Termux" (it's free) and dig around a bit - it's sandboxed, but one can still get some decent info about the environment it runs in...
 
* bit surprised with Nougat support, but hey, it's current enough...
 
Anyways - to check the kernel/etc - go into Kodi, and there, you should be able to confirm the android and kernel versions...
 
Best case - might be a good alternative for the OrangePI Plus 2E...
 
 

Ok, will do... with a very bad stupidphone.

I received the box tonight. I will test it under Android this week-end, and afterwards, lets the butchery begin.

smart!   the connector the user normally only touches once (HDMI, Network, Powering) is on the back-side and connectors which are touched more often (USB) are on the front (assuming IR is normally on the front side). A bit risky but IMO interesting is to throw out the microSD slot. It may solve a bunch of those support questions which end normally here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ (at least the SD related ones ) and 12MB SPI flash is more than enough.  IMO an important 'what if' question:
What if I mess up the bootloader and brick it? I'm not familiar with enough with Amlogic SoCs, are they 'failsave' to unbrick SPI once it's messed up (e.g. something like RKs recovery tools?). I've a talent in messing up u-boot, luckily this only happened on SD-card (of fail-save sunxi) yet, where it wasn't much an issue. I probably pledge for a 1gb version if there are still some left for 19$ when I'm back at home..  Not that I'm interested in Kodi on Linux stuff, still a mystery to me why people want Kodi on Linux (anyway, I don't need to understand everything)..  But I appreciate your contribution towards mainline support for hardware accelerated video en/decoding and it could be a cute little IoT end-node for systems where you can't trust that your device doesn't magically disappears (others would call it someone steals your stuff). At least potential confidential information of this node is not in the wrong hands as soon as they cut power. A cute little toy to get a feeling for PXE related stuff. 

I received the box tonight. I will test it under Android this week-end, and afterwards, lets the butchery begin.

Some SBCs for which Armbian images are available (supported, wip or csc) can be powered via USB-C. Depending on its implementation, some pitfalls must be considered. This short tutorial should give you an overview. 
 
'Dumb mode':
The USB-C connector is used similar to the microUSB connectors in previous SBCs. Means that the pitfalls must be considered when you choose a charger and cable. See the following thread for some background:
Additionally, those boards may be problematic with PD compatible chargers. Without a proper PD implementation those PSUs will only deliver up to 900mA at 5V (4.5W). In case you have a board which isn't PD compliant you should go for a PSU without PD implementation aka 'dumb PSU'. Voltage drop from cable and voltage drop of the PSU at hight load itself must be kept in mind similar to microUSB powered boards!
SBCs which don't support PD (also boards not supported in any form by Armbian):
Vim Vim2 NanoPi M4 NanoPi NEO4 Orange Pi 4  
PD mode (power detection):
With a proper PD implementation, a PD capable PSU can deliver 'more juice' on demand. It's also possible to deliver power at higher voltage (between 5V and 20V). See graphic (12V is missing here):

(source: https://www.digikey.ch/en/articles/techzone/2017/mar/designing-in-usb-type-c-and-using-power-delivery-for-rapid-charging)
To ensure proper powering you should go for a PD compliant PSU. See documentation of your board to see which PD modes are supported within your SBC. Boards known to support PD-Mode:
ROC-RK3399-PC (Renegade Elite)
 
Board:

not really. The tinker can work with RPi cameras e.g. OV5647 and IMX219 as long they've the same pinout (sold as 'RPi compatible') but the kernel must be fixed first.. go through:
and
 
firefly compatibles (not my field cause I don't own it and never spent much attention to it) but there was someone who digged into the OV13850 during ISP1 development:
https://github.com/rockchip-linux/kernel/issues/33
https://github.com/rockchip-linux/kernel/issues/112
https://www.bountysource.com/issues/48831243-rockchip-isp1-driver
 
I had in mind that they got it finally working but no idea where that post is... 
 
I assume this one as compatible.. but that's up to you to clarify it before you buy one..  
https://www.amazon.com/OV13850-Camera-Module-Firefly-RK3288-Optional/dp/B06XBMNH77
 
For the tinker:
https://github.com/chwe17/build/blob/rockchip-default/config/kernel/linux-rockchip-default.config back then 'worked' but for sure the patch series and a bunch of other stuff will be broken now.. go through:
https://github.com/chwe17/build/commit/c26f02b65e6ac1c697b48d7677d1f178017f3994 to get an idea... I somehow lost the interest back then.. 

The only board with a RPi 'compatible' CSI is to my knowledge the tinker... Some RK3399 boards do also have CSI ports but I'm not sure if they've the same pin-out (had in mind that they've mostly a 'firefly' compatible which differs from the 'rpi' compatible). Just check it properly before you choose one.  

Latest RK3399 arrival in the lab. For now just some q&d photographs:
 



 
@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
 
A quick preliminary specifications list:
RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

Please be very careful with these wordings. M.2 is not mSATA. M.2 is just a mechanical connector able to transport a bunch of different protocols. In case you have no other device suited for an M.2 SATA SSD you might want to have a look at https://jeyi.aliexpress.com/store/group/USB3-0-USB3-1-Type-C-Series/710516_511630295.html for external USB3 enclosures (to get a bulky but ultra fast 'USB pendrive'). But since a 'generic' 60 GB SSD will perform crappy anyway and you talked about Amazon the best you could do is to return such a thing right now.

That's amazing. Now I want to Cascade login to as many as possible. #SBCeption

Sent from my Pixel using Tapatalk

Now FriendlyARM has a wiki page for NEO4.

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

testing  testing  testing..  
You need:
a github account a bit of time a SBC armbian supports git clone https://github.com/armbian/testings cd testings ./createreport.sh you don't even need to fork the repo in the browser, we'll do it for you from command line..  Same for the PR, everything is done from console.
 
is back now even for google users... 

If I would have a running windows machine at the moment..  I would test it...  but thanks to @hjc I may copy it partly in the starter..
updated.. I guess there was an u too much in uniq.. But this one should be correct now.
grep "g_serial" * | awk -F. '{print $1}' | uniq  
If you think the average armbian user doesn't know the console you set the bars low  Calling it a serial console is IMO questionable,  serial drivers are loaded a way earlier in the kernel than g_serial. Whenever possible, we should force people to use a real UART-USB adapter and g_serial should only be 'promoted' if the user doen't have a adapter. 

It works great on Windows Server 2016 (so probably Windows 10, too). Now I'm playing with my NanoPi on the desktop workstation in my office.
 

 
It's easy to use, run devmgmt.msc, find the serial device, then go with putty.

Well, if this article is meant to be something for an average Armbian user you should IMO elaborate a bit on what a serial console is and how it's possible over an USB cable. Also not looking at this from the Windows perspective (ignoring +90% of our users?) makes the whole attempt more or less useless. And then I don't understand how you built the list of affected boards (since those the feature has been implemented for are all missing: the inexpensive and headless H2+/H3 boards)