gounthar

Here is some instructions for a raspberry pi
https://www.raspberrypi.org/forums/viewtopic.php?t=132674
 
It has a local and remote network tho, not just a bridge.

Thanks for the info, but it's not compiling the image that's an issue, it's getting a functional u-boot off the SPI NOR with nvme support... I have most of the parts in place, it just does not boot when flashed to SPI. I built an Armbian build just fine and it works on SD, that's not an issue... 
 
There's a lot of info in this thread about progress, as in I'm able to compile a u-boot version with mainline code, I'm able to patch with the files supplied to add nvme support, but none of those u-boot compiled versions end up working when flashed on SPI. There's conflicting information as to what offsets to flash. For example, the package supplied by loverpi flashed idbloader.img at offset 0x00, which is over 900k as opposed to the compiled one which is 236k. Then the package flashes the u-boot.itb at offset 0x4000. I've seen references of offset 0x40000 and 0x200, but none of those combinations work. 
 
Then there's the latest doc supplied by loverpi, which offers NO help whatsoever, as their codebase is almost identical to mainline, which just doesn't work. They do provide an image which covers the entire SPI's 16MB with initramfs and boots.  However, it gives little hindsight about what is required to make a bootable image from mainline, just their fork of the u-boot code. 
 
So again, Libre/loverpi/firefly provides little to no support to get this hardware working with mainline, which is what they keep saying they were aiming to do. This board has INSANE potential if only mainline code could be easily used with ALL their hardware without jumping through hoops. The biggest missing part/irritant right now is nvme support for the mezzanine board and SPI NOR booting. If someone, anyone, is able to figure that part out, then this board will have all that's necessary to serve its intended purpose and we won't ever need support from the board designers/supporters.  This is my goal, as they are in no way helpful.  
 
**edit** upon hex viewing roc-rk3399-pc-spinor.img from the package supplied by Loverpi, seems like u-boot.itb is in the image at 0x40000 as recommended earlier in the thread. Where it gets complicated is flashing idbloader.img so it works. The image seems to have a bunch of padding I can't make sense of.

@Fred St-Pierre if you want to use roc-rk3399-pc you could try using this image: https://www.armbian.com/firefly-rk3399/
The versions with the 4.4 kernel works on mine roc-rk3399-pc, however the usb ports and some gpio don't work.
Versions with the 5.4 kernel do not boot.
Also I don't think nvme works, I have the extension but I don't have a nvme to try it.

Also, I leave here my "armbianmonitor -u" in case someone more experienced than me wants to make an armbian build for roc-rk3399-pc.

Edit: you can compile the image for roc-rk3399-pc by following this guide: https://docs.armbian.com/Developer-Guide_Build-Preparation/

I am also still interested in manual, which explain how to manage HW accel in MPV or VLC at Armbian...

Keep us updated

I just received this little guy:
 
https://www.ebay.de/itm/USB-Li-Po-18650-5V-1A-Lithium-Battery-Protection-Boost-Step-up-Charger-Board/153077054028?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2648
 
Connect one or multiple 18650 cells to it and it will act as UPS. Working very well.
 

@IanHI am connected wireless (only), due to lacking ethernet in the living room. I still get some crashes on ethernet in dmesg.

I am running:
uname -a Linux orangepi4 4.4.213-rk3399 #15 SMP Thu Mar 19 21:33:44 CET 2020 aarch64 GNU/Linux
(Armbian_20.02.5_Orangepi4_buster_legacy_4.4.213)
 
I wonder if anyone knows how to get the Gyrfalcon Lightspeeur 2801S running in armbian?
Also want to make the RPI monitor look nice, including core voltages, does anyone knows which voltage regulators go where?
I found four regulators with suspected cpu voltages, but have no clue on how they are connected
/sys/devices/platform/vdd-log/regulator/regulator.8/microvolts
/sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/regulator/regulator.9/microvolts
/sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/regulator/regulator.10/microvolts
/sys/devices/platform/ff3c0000.i2c/i2c-0/0-0041/regulator/regulator.24/microvolts

Loverpi FINALLY answered me. Here is the documentation to compile u-boot for SPI: 
 
https://github.com/amarula/bsp-rockchip/releases

All working now! it was a bad flashing. I flashed using dd rather than etcher. Also others that had problems used etcher... maybe that was the reason... I used a command like:
dd if=os.img of=/dev/sdX bs=4M status=progress oflag=sync @Belgrado@Pongotto @gounthar

When people will realise, when we will know how to tell them that, that stability of their systems depends from the things like this, then perhaps someone will also follow and wire stuff together, perhaps find it interesting to deal with and do it instead of me ...
 
This is essentially a (cool) tool for us to quickly see how things looks from the users perspective. Now and for the future. With most boards at once. If anyone wants to have this look or help to creates that looks, one shell join. But I don't expect people staying in the line to help out. Even its is in their, ours interest.

IS ANYBODY OUT THERE ???
I have improved the How To, Igor improved the Tool even more.  Will you please give it a chance and test your Single-Board-Computer (SBC)  - who doesn't like to test and tinker ;).  If you depend on your installation do a backup of your SDcard first   and then, please give it a try:  https://github.com/armbian/autotests
Report back here or on github if bad or good. If good even more, who doesn't like to hear it works well.
 
Thank you
 

I just ordered two units  
 
 
I know for some I will still need to use something else, but most it will cover. The price is reasonable, yes.
 
... not working anymore

You make a good point! I will contact some of these sellers and offer them a low amount. It will be a nice device to learn and tinker with and it shouldn't be too difficult to hunt down a SDK for this somehow somewhere. Which might make it easier to get Armbian on this. This box could make a nice little router or access point or something. I'm mostly sold on the form factor to be honest. I got a weak spot for these kind of boxes. I hope I can get my hands on one or two at a nice price. 
 
As for your power bill, I charge powerbanks using one of those 'camping' solar panels and use those powerbansk to run sbc's on. During day time the pass trough charging makes sure all the banks are filling up and at night there's enough juice left to last all night. And to be honest my main sbc doesn't take much at all. I have a bunch of NanoPi NEO2 boards and as Pihole or little webserver they're usually under 100ma at 5v. Very very little.
 
You could also get one of those chargers they had for the OLPC laptops. They have this foot pedal or crank to generate power. Charge powerbanks with it that are powering your sbc, or build your own desk 

 

I have to take back my statement that any recent compiler shout be able to build a working u-boot, spl combo. To be self contained I build u-boot, spl on my roc-pc and flashed the result to the spi flash and it doesn't work! Bummer.
 
I had to debrick the board with the version I have cross-compiled on my Arch Linux PC. At the moment on the distribution my board is a Manjaro Arm Linux.
 
I am baffled and have to think how to continue.

I found the answer to my question. Working library for Orange PI 4:
https://github.com/orangepi-xunlong/wiringOP
 
 

You are running the script on your desktop / server. It scans armbian boards on the network. If you set SUBNET, it will scan for devices on that subnet. I have dedicated subnet for testing armbian devices. I only hook power and network cable and they are ready for this script. I don't need to do nothing else.
 
If you only run a few devices in your only subnet, use HOSTS and type there IP addresses of devices you want to run tests on.
 
 
Put your phone BT to discoverable mode and run:
hcitool scan on a Linux computer that has BT dongle.
 

Welcome to try adding those hints.

I have 25 boards in the automated testing facility ATM  and this is how the report (with bugs) looks like:
 

Do you happen to be using the same SD card that you used previously for Xunlong's BSP?
If so this is a known issue: 
 

Same here (I think @tkaiser shared this model here and everybody copied his idea). 

Steps for building native on the board, boot from mmc or SD:
 
Get https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
make -j6 PLAT=rk3399 bl31
cp build/rk3399/release/bl31/bl31.elf ../u-boot
 
cd ../u-boot
 
make roc-pc-rk3399_defconfig
make -j6
 
dd if=idbloader.img of=/dev/mmcblkX seek=64
dd if=u-boot.itb of=/dev/mmcblkX seek=16384
 
If this works, you can try SPI.
 

I bought a DEALDIG BOXD6 (s912 3GB/32GB) with seems a clone of a Beelink GT1 Ultimate.

This box works great with Armbian (bluetooth, WiFi):
    _    __  __ _     
   / \  |  \/  | |    
  / _ \ | |\/| | |    
 / ___ \| |  | | |___
/_/   \_\_|  |_|_____|
                      
Welcome to Ubuntu Eoan with Armbian Linux 5.3.0-aml-g12
System load:   0.00 0.14 0.25   Up time:       20 min           Local users:   3            
Memory usage:  14 % of 2805MB   IP:            169.254.5.80 192.168.0.124
CPU temp:      50°C           
Usage of /:    42% of 28G    

0 mise à jour peut être installée immédiatement.
0 de ces mises à jour est une mise à jour de sécurité.
*** /dev/mmcblk1p2 will be checked for errors at next reboot ***
*** /dev/mmcblk1p2 will be checked for errors at next reboot ***
Last login: Fri Dec  6 14:19:08 2019
 
inxi -Fxs System: Host: Dealdig-BOXD6 Kernel: 5.3.0-aml-g12 aarch64 bits: 64 compiler: gcc v: 7.4.1 Console: N/A Distro: Ubuntu 19.10 (Eoan Ermine) Machine: Type: ARM Device System: Amlogic Meson GXM (S912) Q201 Development Board details: N/A Battery: Device-1: hidpp_battery_0 model: Logitech Wireless Touch Keyboard K400 Plus charge: 55% (should be ignored) status: Discharging CPU: Topology: 8-Core (2-Die) model: ARMv8 v8l variant: cortex-a53 bits: 64 type: MCP MCM arch: v8l rev: 4 features: Use -f option to see features bogomips: 0 Speed: 1512 MHz min/max: 100/1512:1000 MHz Core speeds (MHz): 1: 1512 2: 1512 3: 1512 4: 1512 5: 1000 6: 1000 7: 1000 8: 1000 Graphics: Device-1: meson-gxm-dw-hdmi driver: meson_dw_hdmi v: N/A bus ID: N/A Device-2: meson-gxm-mali driver: panfrost v: kernel bus ID: N/A Display: server: X.Org 1.20.5 driver: modesetting unloaded: fbdev resolution: 1920x1080~60Hz OpenGL: renderer: panfrost v: 2.1 Mesa 19.2.1 direct render: Yes Audio: Device-1: meson-gxm-dw-hdmi driver: meson_dw_hdmi bus ID: N/A Device-2: meson-gx-audio-core driver: meson_gx_audio_core bus ID: N/A Device-3: simple-audio-card driver: asoc_simple_card bus ID: N/A Sound Server: ALSA v: k5.3.0-aml-g12 Network: Device-1: meson-gxbb-dwmac driver: meson8b_dwmac v: N/A port: N/A bus ID: N/A IF: eth0 state: down mac: 98:13:39:XX:XX:XX Device-2: pwm-clock driver: pwm_clock v: N/A port: N/A bus ID: N/A IF-ID-1: wlan0 state: up mac: 10:d0:7a:XX:XX:XX Drives: Local Storage: total: 28.91 GiB used: 11.60 GiB (40.1%) ID-1: /dev/mmcblk1 model: SLD32G size: 28.91 GiB Partition: ID-1: / size: 27.57 GiB used: 11.50 GiB (41.7%) fs: ext4 dev: /dev/mmcblk1p2 ID-2: /boot size: 121.7 MiB used: 99.9 MiB (82.1%) fs: vfat dev: /dev/mmcblk1p1 ID-3: /var/log size: 48.4 MiB used: 7.3 MiB (15.1%) fs: ext4 dev: /dev/zram0 Sensors: Message: No sensors data was found. Is sensors configured? Info: Processes: 258 Uptime: 7m Memory: 2.74 GiB used: 914.2 MiB (32.6%) Init: systemd runlevel: 5 Compilers: gcc: 9.2.1 clang: 9.0.0-2 Shell: bash v: 5.0.3 inxi: 3.0.36  

RFC on auto tests. Ideas how to shape this script are welcome!
 
Its getting better and better so I hope we will soon be able to make regular use of it and equipment from the topic  

Yeah that might work.
 
Keep in mind though that this module will still output 3.3V if the input is lower than 5V. Checking the datasheet http://www.advanced-monolithic.com/pdf/ds1117.pdf it seems like this regulator has a dropout voltage of about 1.2V. So 4.5V input would still allow this module to output 3.3V signaling to your SBC that everything is OK while at 4.5V input to your SBC it will probably fail.
 
This is obviously not ideal!
 
EDIT: Easiest way to do it would be to instead of the converter just use a potentiometer (10k or something like that). Connect the ends to 5V and GND, and adjust it until the slider is at about 3V (measure with multimeter). Then attach the slider pin to some GPIO and check GPIO state. Keep turning down the voltage just until the GPIO reads as LOW. Turn back up a bit until it is HIGH. Then once the input drops below 5V the poti output will also drop slightly causing the GPIO to go LOW -> use this as shutdown. 
 
This is also not perfect, beware: never turn the poti to high (watch out for anything >3.3V on your GPIO) also you might have to experiment 'till you have a good setting. Minor power fluctuations should not cause a shutdown. 

Any update on this topic ? Did anyone managed to run MPV with HW Video acceleration on 5.3+ Kernels from Armbian ?

It arrived!
This is going to be a non-professional tear-down and quite a WIP!
 
The intent of posting this up was not just to show off a cheaply found / obscurely deployed rk3399 board, but to possibly open development using Armbian.
If possible, boards like this and other hidden gems that might pop out of the woodwork as we may find them may come with amazing things only found at usually outrageous prices  for the business market.
 
As I found this, it was intended to be a $400-600 DIGITAL SIGNAGE MODULE sold to education private and public I suppose. For one reason or another the modules themselves are being sold near mint, at anywhere from $40-100. A fair price for something that is just parts at worst. Still, the hope and GOAL here is to attempt as much hillbilly hackery as possible to see what else can be done, and armbian seems to be the most hopeful solution for an OS.
 
Any suggestions are welcome, technical, critical, or otherwise that might improve interest as such;  BUBBA proudly present and DESTROY
smart technologies am40 rk3399 module - now with more pie and banna!
 
 
Technical Stuff
 
guideam40installv31aug17.pdf - The manual that comes with the module product new in box. It also requires a smart tv with touch capability to insert it into. I would rather install a 3rd party touch screen such as raspberry pi 7-10 inch touch screens like any normal rk3399 sbc..
 
For now however, I've attached the "module" to something more familiar, pictured here:
 


 
 
comparisoniqappliances.pdf
 
Comparison of the different modules you may find for various prices with a similar chip-set. The am50 do look cool, but Bubba can't find one priced to destroy.
 
Photos:
sorry for the terrible camera filter I had on. posted anyhow to show general size of board. surprised it 1 pound!
 
Front - with added 1 antenna (can have 2)

 
Rear - Serial Port (including power) aka: Open Plug-gable Specification

 
Side - Service Switch (used for booting operating system of SD I believe, hope for armbian)

 
 
Inside:
"disclosure fitting for rockchip"
 
Bubba am not certified to do anything except destroy. To give you an idea, Bubba had to carry a rock to tech school during basic electronic week for dumb as rock answer. A week how long it took to realize there's rocks everywhere and Bub didn't have to carry a rock for  a week in the first place!
 
Anyone who already didn't know, (me had to research) the Rockchip that's not under the heat-sink is : RK808 is a complete power supply solution for Portable systems. The highly integrated device includes four buck DC-DC converters, eight high performance ldos, two low Rds switches, I2C interface, programmable power sequencing and an RTC.
 
Have yet to remove the heat sink, its a beast now that I think about it.. I'll put my m4 on top of it for a comparison photo later.
 
 
Nomenclature

Heatsink HEATSINK!
RK808-D

UART Debug and logic levels

RTL8822BE removable

"service switch" labled ADB

 
 
Power I/O
seemed hidden by chasis housing, Bubba destroy a hole into it later for easy access

 
From these photos, does anyone know if this is a carrier or dev board native to any Armbian already supports? Thoughts, corrections, and feedback are welcome.
 
 
Destroy with caution!
 
 
 

 
This was tricky. The board was free of all mounting, except the adhesive around the front pannel jacks. Bubba destroy carefully here