aaditya

My topic (my February 9 post) was merged into this one but it turns it incorrectly. Now that I've debugged it, and can see my original problem more clearly, it was basically this: the problem I had in was that the idbloader.img (loaded from the eMMC) tries to boot the next stage (u-boot.itb) from the SD card, because of the patch in patch/u-boot/u-boot-rockchip64-dev/board_rockpi-4b/001-boot-order-prioritize-sd.patch and instead I wanted to boot all stages from the eMMC and use the SD card as storage. But if the SD card is present, armbian's idbloader tries to load later stages from there and then crashes. I'll attach what I've seen on the serial console, just for reference if someone has the same probem.
 
The solution was to simply delete the 001-boot-order-prioritize-sd.patch file and build the image like that. In that case, the whole boot sequence is loaded from the eMMC and I can use the SD card as storage.
armbian_boot_with_sd.txt

Recently we been finding some very clever spammers who register, make some post(s) that sound at least somewhat on topic, and then come back days or even weeks (!) later and edit them in order to insert spam links. Some examples:
 

 
Some times they put them alongside otherwise legitimate links:
 

 
Other times, they sneak them into quotes or lists, etc.:
 

 
Now, above examples have red background from being deleted (which is not how they will look to you normally) but you get the point.
 
There is no way for us currently to detect this kind of spamming, without enacting draconian measures of moderation, which we are certainly not going to do. So instead we ask for your help. The only way to really find these is to happen upon them while browsing the forum. If you see one, please click on the little flag at the bottom and a Moderator will take care of it. It only takes 2 seconds, and you can help out in keeping the forums a nice and useful place.
 
I also want to mention that something does not have to be Spam, or otherwise "bad" for you to Flag it. Anything that you feel deserves Moderator attention, such as off topic, or a diverging thread that needs to be split up into 2 or more separate topics, etc. can be Flagged.
 
Any forum Member can do this, it requires no special permissions whatsoever.
 
Thanks for your help!
 
Note: This post is geared toward every Member / user of the forums. The corresponding post geared more toward Moderators about how to deal with these kind of posts (once Flagged) can now be found here.
 

Armbian is here for 7 years. Only last / this year this is becoming relevant. Only SPI boot is problematic, while our standard way of installing a system - boot from eMMC/SD and root on SSD / HDD ... doesn't care about partition type. It can be anything.
 
Providing as unique experiences across different hardware as possible is very important. For us and for you.
 
We should start thinking about this, agree ...

it was highly overpriced with 400-600$ (IMO still 100$ are too much for it) it is mostly undocumented what you got is a 4GB ddr3 rk3399 'TV box' with 2x2 wifi over mPCIe and 32GB eMMC with a 'connector' I've not seen any specification what's populated on it
. which may or may not work with a 'generic DT' (generic means here any rk3399 dt file we have most of them are quite similar cause they follow more or less the reference design) for rk3399 boards. You can also (try to) 'extract' the dtb file from 'whatever is preloaded' on this box.. decompile it and follow all the phadles to see how nodes are connected to each other.. to adjust a working DT to match the box better or write one from plain.. (you can also use this blob directly on any sort 'armbian' and see if it is compatible).
 
at least it has a debug UART populated (likely 3v3 but who knows, you should check that first)
 
Is it worth it.. well that's up to you.. if you're interested in going down the rabbit hole and learn new things.. maybe it is (you can spend a lot of time with bootloaders, device tree etc. on it.. IIRC ddr3 should be supported with mainline u-boot, and what they have labeled 'service only' looks like a SD-card holder, so you can likely do your 'try and error attempts' to get something 'armbian a like' booting on this board without corrupting the OS which is currently preflashed on the eMMC.
likely similar to that stuff here:http://wiki.t-firefly.com/en/Firefly-RK3399/adb_use.html
 
So to summarize you currently got a paperweight and it's up to you to transform it in something useful. Even then I don't see much of a reason to provide support on such a board. It has a 'unknown' availability (you got it cheap from ebay, but as soon as this sellers run out of stock, it's likely never appearing again). For 100$ you get the nanopi m4v2 with a case which offers known schematics, support from the boardvendor, known connectors (including eMMC, PCIe, hdmi, camera and display interfaces) and the vendor known in SBC marked for years (they may not do everything perfect but you mostly know what you get, and in general those boards work as they should). This box might be nice if you plan to learn and dig into what can make it a pain to support random boxes with 'somehow' proper working images. But you may have to build your images on your own for a long time in case non of the images we provide for rk3399 will work out of the box (I would focus on images built for ddr3 ram type boards).

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
 

 

 
 
             

 

Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
 
Now it looks more clear and a bit unfortunate... ;-)
U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
 
Now the positive stuff...
@raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)

I would add the mentioned options to kernel config, built the kernel, copied resulting ".config" file over "linux-rockchip64-current.config" and then commit it.
It would be great to do the same with "dev" kernel (which is now 5.5.y in Armbian's master) in the same PR for feature parity  

I've built Armbain (5.4.17-rockchip64) from sources with additing the next options CONFIG_BT_HCIUART_SERDEV=y,  CONFIG_BT_HCIUART_H4=y, CONFIG_BT_HCIUART_BCM=y to linux-rockchip64-current.config.
And bluetooth is working.
 
brcm_patchram_plus_rk3399[1446]: Done setting baudrate Feb 3 20:28:32 localhost kernel: [ 99.787745] Bluetooth: Core ver 2.22 Feb 3 20:28:32 localhost kernel: [ 99.787784] NET: Registered protocol family 31 Feb 3 20:28:32 localhost kernel: [ 99.787787] Bluetooth: HCI device and connection manager initialized Feb 3 20:28:32 localhost kernel: [ 99.787797] Bluetooth: HCI socket layer initialized Feb 3 20:28:32 localhost kernel: [ 99.787802] Bluetooth: L2CAP socket layer initialized Feb 3 20:28:32 localhost kernel: [ 99.787809] Bluetooth: SCO socket layer initialized Feb 3 20:28:32 localhost kernel: [ 99.800667] Bluetooth: HCI UART driver ver 2.3 Feb 3 20:28:32 localhost kernel: [ 99.800672] Bluetooth: HCI UART protocol H4 registered Feb 3 20:28:32 localhost kernel: [ 99.800829] Bluetooth: HCI UART protocol Broadcom registered Feb 3 20:28:32 localhost brcm_patchram_plus_rk3399[1446]: Done setting line discpline Feb 3 20:28:32 localhost systemd[1]: Starting Load/Save RF Kill Switch Status... Feb 3 20:28:32 localhost systemd[1]: Starting Bluetooth service... Feb 3 20:28:32 localhost systemd[1]: Started Load/Save RF Kill Switch Status. rock@rockpi:~$ hciconfig hci0: Type: Primary Bus: UART BD Address: 43:45:C5:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:1186 acl:0 sco:0 events:77 errors:0 TX bytes:3609 acl:0 sco:0 commands:71 errors:0 rock@rockpi:~$ sudo hcitool lescan LE Scan ... D8:2D:27:A6:53:45 (unknown) D8:2D:27:A6:53:45 Mi Smart Band 4 F8:D8:37:3D:17:75 (unknown) F8:D8:37:3D:17:75 Mi Smart Band 4 ... but only after a cold boot, as @piter75 said.
 
Who knows what is a right way to make changes in Armbian sources to fix Linux kernel options for Rock Pi 4?
I want to make pull request.

What I ended up doing for NanoPC T4 is disable the systemd service and in rc.local:
/usr/bin/brcm_patchram_plus_rk3399 --enable_hci --no2bytes \
  --use_baudrate_for_download --tosleep 200000 --baudrate 1500000 \
  --enable_lpm --patchram /lib/firmware/brcm/BCM4345C5.hcd /dev/ttyS0 &
 
> ... bluetooth doesn't work and I've got a flood in Rock Pi 4 syslog
 
The --enable_lpm stops the flood and allows it to more-or-less complete.
 
FWIW I haven't yet seen an Armbian 5.x kernel where both wifi and bluetooth actually worked on the T4, but I haven't tried 5.x since I started messing around with brcm_patchram so maybe ... 
 

I didn't have time and enough interest in Bluetooth to pursue a solution but one thing I have noticed with 5.x kernels on all rk3399 boards I own is that Bluetooth's firmware is correctly patched after cold boot / power on but not after a reboot.

Important information for Rockchip RK3328\RK3399 and Allwinner H6. If you have written to the SD card any version of the system that uses a GPT table or a non-standard u-boot (for example, an Android image or an Ubuntu image built by the device manufacturer, etc.). Before writing an Armbian or Libreelec image, be sure to zero the entire SD card with the
 
dd if=/dev/zero  of=/dev/<sd_card> bs=64M
 
command. Only then can you write the image to the SD card and it will work correctly. If you do not zero the SD card, there will be problems with u-boot from Armbian and Libreelec (u-boot does not start and stops with a partition table error message). For those who use the new version of u-boot, which supports direct launch from USB media, I recommend using USB media to launch, this guarantees that the system will start, regardless of what was previously on the USB media.

I think with the next LTS mainline kernel this will be possible. Right now there are still a few odds and ends, RK3399 is not as well supported as RK3288, for example. It's far better off than RK3328 though. We have some fragmentation of the RK3399 boards due to bootloader difficulties with RAM, Rockchip has been extraordinarily slow to improve LPDDR4 support

Sent from my Pixel using Tapatalk

IMO there's no reason to rush here.. before we haven't cleaned some of the mess in bootloaders I don't see much of a reason to change things. Yes the boards run surprisingly stable, but there are still odds here and there. I think most of the overlay features are not fully tested (compile log at least indicates that some of them might need some inspection as well) and we still have various kernel sources for the bsp kernel which needs to be cleaned first, and as just noticed, the odds regarding rebooting starting again with the pinebook.. There isn't much of a difference between the bugtracker forums and the dev forum at all. 
 
And 4.4 kernel gets old (no matter it is supported well or not), so might hit the fallout of this with the next versions of debian/ubuntu. So the same thing happened with 3.4 on sunxi shouldn't bite us again (kernel to old for recent ubuntu/debian but a bunch of interesting features are only available there).
 
they could be marked, "potential harmful to your family" and people would still use it productive... our "supported" definition is so generic (https://docs.armbian.com/#what-is-supported) that it means in fact nothing.. (I'll burn in hell for that statement I know).. At least when people run into problems they should be aware that things are working progress right now. Most basic seem to work without major issues, but for everything a bit more fancy (camera, display etc) there's not much tested and proved to work right now. Multimedia works only on half of the boards (those belong to rk3399).

I think you might be right. But I split your topic off to it's own for discussion.
 
@TonyMac32 made a similar comment (I think in IRC?) the other day, but I wanted to gain more of a consensus before taking any action as I am no where near as familiar as Devs (or probably even some users) on this subject.

If you are a moderator, you need to be ready to "put in place" those who do not recognize the rules and do not react to their negativity. The moderator's position is initially conflicted, you need to be prepared to reasonably ignore the negative from those who are not happy.

I took an image from NanoPC T4 (can take any for rk3399), recorded it on USB, configured DTB for RockPi-4b and voila, the system normally starts and works. That is, can have one universal image and run it on any model (do not have to build and place many different images on the site, which differ only in u-boot). If desired, can easily add the desired u-boot for a specific model and use the launch from SD\eMMC. 

You might want to use the  dts from  Toobias Schramm's Manjaro source  Most things are working very well.   Someone else has built a mainline u-boot which  can be run from Spi flash (but doesn't support NVME boot yet--an earlier version based on Rockchip does.)  Manjaro for Pinebookpro is now running with 5.5 rc-something kernl,   The only thing that I have found not to work is suspend,  which people are still trying to make work on mainline.   Check the  Pine64 forum for more info.  I had started to try to test an armbian build,  but it takes me forever to figure out  the scripts.   
 
I think mainline uboot with mainline kernel is a good way to go...
 
If any one needs any testing/test building  let me know. 
 

I have taken another route with this PR.
I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
Higher MTUs would require further shortening of the PBL.
 
I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.

Network issues are solved upstream.
eMMC tweak for your board is not in the build system yet. I will prepare it soon and give you a shout.

Hi. I use the NanoPi M4V2 as main desktop. Works great with the default kernel and the media script from jmcc.
Video playback for youtube is 1080p 30fps or 720p60fps. While video files up to 4k can be watched. 

In mainline we're working on getting good video playback. Now that only works in default kernel, but GPU drivers now work in mainline.

I've got many other sbc's. None that is this powerful, has such good software, and great I/O with the PCIe gpio's.
Greetings.

Have used the RockPi4b for several months as my main computer.

Thanks a lot aaditya

See my post regarding Armbian for Rock Pi S on Radxa's forum.
 
Since then:
kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested.
I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks.
 
Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6.
I will probably prepare a "dev" kernel with one of 5.5 RCs soon.

https://github.com/sgjava/userspaceio already does this, but using the latest userspace libraries. I took a peek at mraa and the gpio source uses sysfs which is deprecated. See https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython/ No need to bake this into Armbian in my opinion. Also, I can install Userspace IO on other Linux distributions besides Armbian, so I'm not limited to a distribution.
 
This whole idea of mapping pins the same seems kind of silly to me since a lot of my SBCs have a variable number of GPIO pins, some have multiple I2C, some have multi purpose pins, etc. This is something that should be done a layer above the actual APIs and is trivial to implement (using a pin map or table).
 
There's no wheel reinvention going on here. I started Userspace IO over 2 years ago and it still remains the only true cross SBC API (there is no need to detect board type). Basically if your kernel is > 4.8 and supports devices mapped to userspace then it should work. mraa has limited ARM support (Pi is the only ARM SBC supported that I have out of 10 different SBCs).
 
As far as non-root access see https://github.com/sgjava/userspaceio#non-root-access
 
I'd love to just install Linux and have everything working, but that's not reality now. I'm not dissing mraa, but it's not something I'd use personally.
 

blind-shot to try to debug doesn't make sense. Without the (full) console log it doesn't make sense to step into this. So first, make sure you connect to the right UART to get the debug output.
For the bootorder:
https://lists.denx.de/pipermail/u-boot/2017-April/285493.html
http://rockchip.wikidot.com/boot-sequence
(even when I'm not sure the second one is fully complete, I guess it's mostly achieved over the choosen node)
 
if you look at the sources of radxas bootloader, and we assume that's the one which is on your eMMC:
https://github.com/radxa/u-boot/blob/6d910b7f12318e5a5bb8d1b2093fe5a9ba17dfce/arch/arm/dts/rockpi-4b-linux.dts#L26
chosen { stdout-path = &uart2; u-boot,spl-boot-order = &sdhci, &sdmmc; };  
in their u-boot eMMC should have priority over SD card. If you now look on our bootloader:
chosen { stdout-path = &uart2; }; it's not as clear anymore.. according to rockchip it should look in SD-Card first. But I could be that they achieve this over the choosen node, no idea what happens then if it's not defined there. Also their docs rely on their u-boot. We used a patched one based on theirs.. So another option where things can change. A bunch of variables and things go messy.
 
 
debugging your issue without a bootlog isn't a option for us. So either you can provide a full bootlog (and that starts a way earlier than when the kernel takes over) or you've to follow @martinayotte recommendation and remove the eMMC.
 
BTW for the rockchip maintainers here (adding @TonyMac32 @piter75) It might make sense to add a proper choosen node to all our DTS files to get a predictable bootorder for all RK3399 boards.