Jump to content

RockPi 4b 'board bring up'

chwe

By chwe
in Rockchip

 Share

Recommended Posts

chwe

chwe

Posted
Posted (edited)

This thread summarizes the efforts done to get armbian support for the new RockPi 4b.

 

ROCKPI4B_Angle_View.png

 

Boardspecs (from: https://wiki.radxa.com/Rockpi4/getting_started):

 

  • Rockchip RK3399
  • 64bit dual channel LPDDR4@3200Mb/s, 1GB/2GB/4GB optioal

storage:

  • eMMC module (optional)
  • uSD card
  • M.2 SSD (M.2 connector supports up to 2T M2 NVME SSD)

display:

  • HDMI 2.0 up to 4k@60
  • MIPI DSI 2 lanes via FPC connector

other features:

  • 3.5mm jack with mic
  • MIPI CSI 2 lanes via FPC connector, support up to 800 MP camera.
  • 802.11 ac wifi
  • Bluetooth 5.0
  • USB 3.0 OTG X1, hardware switch for host/device switch, upper one
  • USB 3.0 HOST X1, dedicated USB 3.0 channel, lower one
  • USB 2.0 HOST X2
  • GbE LAN with PoE support (hat required!)
  • 40-pin expansion header
  • USB PD, support USB Type C PD 2.0, 9V/2A, 12V/2A, 15V/2A, 20V/2A. (supports Qualcomm® Quick Charge as well)
  • 85mm x 54mm

 

Current support status (and some background):

first dev samples arrived and @martinayotte and @TonyMac32 started to integrate it into the rockchip64 boardfamily. Radxa offers a patched kernel and u-boot based on rockchips out of tree 4.4 kernel and 2017.09 u-boot. The our rockchip64 family is based on @ayufan s u-boot (which is a fork of rockchips) but a simple patch in of raxdas defconfig and the needed devicetree files don't work (it breaks on several parts during compilation related to USB and other stuff I'm still not 100% sure why.. :ph34r::lol:). So we went for a defconfig and DT file based on the one of the RockPro64 (cause even without patching, those images booted - a lot of stuff didn't work but at least it allowed us to start getting things working).

People related to Radxa forked the buildscript (https://github.com/brian541/build) and I assume that's why they can provide some 'preview' Armbian images on their site. Problem here is that they defined their kernel and their u-boot in a new linuxfamily (https://github.com/brian541/build/blob/master/config/sources/rk3399rockpi4b.conf) we simply can't have another RK3399 boardfamily (we have two, they share the kernels but not u-boot cause some boards have issues with upstream u-boot - we don't want to manage another u-boot fork nor another 4.4 kernel, it's ayufans or upstream).

That's why things may need a bit of time until they work properly on the RockPi.

 

Currently working (rockchip64-dev branch):

GbE

USB

Wifi (but laggy)

SD-Card (seems to be fine now)

HDMI (not committed yet)

 

Currently broken or with issues:

SD-Card has random hangs (probably speed issues)

 

everything else must be expected as broken at the moment. As far as I know nobody is currently working on 4.4 images and it might need some time to bring things up there. So RockPi 4b images must be considered as early wip at the moment and have to be built on your own cause we don't provide images yet.

 

side-note: first patches are also upstream to support the board in mainline kernel (not done by us https://patchwork.kernel.org/patch/10745929/)

 

@martinayotte & @TonyMac32 can you please correct in case I screwed something up in my summary? :D:ph34r:

 

@Igor or @zador.blood.stained if you think the thread fits better into the 'board bring up' subforum just move it. ;)

Edited by chwe
updated (3/x)
3
martinayotte

martinayotte

Posted
Posted
  On 1/4/2019 at 7:30 PM, chwe said:

Currently broken or with issues:

SD-Card has random hangs (probably speed issues)

Expand  

As per @TonyMac32 suggestion, I changed sdmmc pins to get higher strength, and committed that yesterday, it seems to fix the issue.

Tony had also the HDMI working last night, but he didn't committed that yet, too tired to avoid going to sleep ... ;)

1
TonyMac32

TonyMac32

Posted
Posted

The HDMI should be committed, I didn't fix a couple things I noticed on pcie and the audio codec yet. ;-). The Wlan may also be better, the Radxa device tree sets the io to 20 mA across the board on it, committed with hdmi. @Martinayotte, if you would verify it works, I didn't try to bring it up yet.

Sent from my Pixel using Tapatalk

chwe

chwe

Posted
  • Author
Posted

suggestion: let's combine all DT patches once most of the stuff is working.

 

btw. I may work a bit on 4.4 kernel this weekend and if the basic stuff is working I may go down the CSI rabbit hole once again to see if we get the camera working with ISP1 :ph34r: (just out of fun :lol::rolleyes: - having a new idea for the lab where this board would actually fit quite well for some image recognition shit which could be funny :ph34r:)

Dante4

Dante4

Posted
Posted

Anything just user (as is no creating drivers experience) can help with?

 

Or second thought, let me rephrase question. What kind of skills may be useful at this and next steps?

TonyMac32

TonyMac32

Posted
Posted

This early on that is a tough one, most of the work is basic board support, so device tree/etc.

Sent from my Pixel using Tapatalk

Dante4

Dante4

Posted
Posted
  On 1/7/2019 at 7:16 PM, TonyMac32 said:

This early on that is a tough one, most of the work is basic board support, so device tree/etc.

Sent from my Pixel using Tapatalk
 

Expand  

yeah...that require to understanding what you need to find without google all the time.  

chwe

chwe

Posted
  • Author
Posted
  On 1/7/2019 at 6:16 PM, Dante4 said:

Anything just user (as is no creating drivers experience) can help with?

Expand  

 

you can start with testing: https://github.com/armbian/testings

maybe not yet for the RockPi 4b but for other boards you have?

 

  On 1/7/2019 at 7:26 PM, Dante4 said:

yeah...that require to understanding what you need to find without google all the time.  

Expand  

google is a good helper which I quite often use. :)

 

If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step. :)

 

You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.

2
Dante4

Dante4

Posted
Posted
  On 1/7/2019 at 9:20 PM, chwe said:

 

you can start with testing: https://github.com/armbian/testings

maybe not yet for the RockPi 4b but for other boards you have?

Expand  

That i can do for sure for renegade-default (if i understand correctly it's my roc-cc aka Renegade)

 

  On 1/7/2019 at 9:20 PM, chwe said:

google is a good helper which I quite often use. :)

 

If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step. :)

 

You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.

Expand  

I do agree with this, but i know difference between "let google this and this" and "google what the hell is this?" right now i'm more about 2nd. But wanna to become closer to first.

Thanks for your advice :), since I do have alot of spare-time for now i will dive in.  (would prefer to not fry anything... -_-'''')

chwe

chwe

Posted
  • Author
Posted
  On 1/7/2019 at 9:28 PM, Dante4 said:

I do agree with this, but i know difference between "let google this and this" and "google what the hell is this?" right now i'm more about 2nd. But wanna to become closer to first.

Expand  

As most of us were in the beginnings.. ;)

 

  On 1/7/2019 at 9:28 PM, Dante4 said:

(would prefer to not fry anything... -_-'''')

Expand  

I don't guarantee but I think it's not that easy to fry something with a wrong devicetree.. It's a way easier with connecting random crap to the pin-header.

 

Since you want to get closer to group 1 let's give an example:

 

That's the original DT for the RockPi4b (4.4.x kernel) spoiler cause it just messes up to show the whole one for everyone (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts):

  Reveal hidden contents

 

the first few lines after comment tell us which other DT files are included here e.g. (rk3399.dtsi): 

#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/input/input.h>
#include "rk3399.dtsi"
#include "rk3399-linux.dtsi"
#include "rk3399-opp.dtsi"

basically just another 'layer' of describing hardware, since a lot of stuff is shared with all rk3399 based boards this stuff is usually described once there and the nodes are used again and again for every board.

 

The nodes after it describe the hardware and how it is connected (also partly software e.g. there are multiple UARTs available, a node has to tell the kernel which one should be used to output the debug console).

 

Now let's look at such a node: 

	fiq_debugger: fiq-debugger {
		compatible = "rockchip,fiq-debugger";
		rockchip,serial-id = <2>;
		rockchip,signal-irq = <182>;
		rockchip,wake-irq = <0>;
		rockchip,irq-mode-enable = <1>;  /* If enable uart uses irq instead of fiq */
		rockchip,baudrate = <1500000>;  /* Only 115200 and 1500000 */
		pinctrl-names = "default";
		pinctrl-0 = <&uart2c_xfer>;
};

the compatible part is the first one which is interesting cause it gives you some hints where you get further information. :) (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt)

From there you get most of the information out what this node does and how it can be configured.. E.g. for the fiq node, it could be worth to set baudrate to 115200 cause this is the common baudrate for all SBCs (except rockchips which often favor higher baudrates for whatever reasons :ph34r:). So obviously when you connect an USB-UART you've to set it to 1500000 not the default 115200 (keep in mind, if it's patched in the kernel, it should also be patched in u-boot, otherwise things get messy).

 

That's just a short introduction and you've to read a lot of stuff until all this stuff makes sense. :P Maybe I write something about the buildsystem tomorrow.

3
chwe

chwe

Posted
  • Author
Posted

so today we're talking a little bit about the buildscript (likely that those posts will be splitted out into it's own thread to build up a miniseries of tutorials)... I just talk about basics of it. To be honest, I don't know every part of it fully but for detailed questions there are people here which can answer specific parts. For the simplicity we assume that the SoC on the board is a supported one (rk3399 is). A basic overview with tree -L 2 to get a overview:

  Reveal hidden contents

 

  • cache: to avoid downloading the sources again and again every time you build an image and saving you time to build images, armbians build-script caches sources (e.g. rootfs, kernel sources, u-boot sources, atf, compilers - out of tree sources can't always be compiled with the newest compiler versions so we also have some older ones)
  • config: basic configuration files for your board, the kernel and sources we use.
  • config --> board: an armbian specific boardconfig file, for the RockPi 4b it looks like the follwowing: 
    # RK3399 hexa core 2G/4GB SoC GBe eMMC USB3 WiFi
BOARD_NAME="RockPi-4B"
BOARDFAMILY="rockchip64"
BOOTCONFIG="rockpi4b-rk3399_defconfig"
#
MODULES=""
MODULES_NEXT=""
#
KERNEL_TARGET="default,dev"
CLI_TARGET="stretch,bionic:default"
DESKTOP_TARGET="stretch,bionic:default"

CLI_BETA_TARGET=""
DESKTOP_BETA_TARGET=""

    BOARDFAMILY tells you which sources it uses (later more on that).
    BOOTCONFIG telly you which xxx_defconfig file in u-boot will be used (maybe something for an u-boot plumber tutorial follow up) Modules is only needed if you've to install special modules to enhance functionality (something for a more detailed tutorial).
    KERNEL_TARGET (will be explained in sources), CLI_TARGET (which flavors of Armbian you can build (here we provide only ubuntu bionic and debian stretch for some older kernels we've to provide xenial as well cause they're not able to work properly with stretch or bionic).
    DESKTOP_TARGET - same as CLI but with a DESKTOP (e.g. we don't provide DESKTOP images for boards without HDMI etc.). CLI_BETA_TARGET not of interest yet.

 

  • config --> kernel (the .config file you normally get with make ARCH=arm xxx_defconfig if you compile kernels on your own - our configs differ often from defconfigs provided by kernels often to enhance functionality)
  • config --> sources as you can see, the RockPi4b is part of the rockchip64 family therefore (https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf):
      Reveal hidden contents
     

    for a beginner, most of this configs here can be ignored cause it needs some knowledge to deal with but a few interesting parts will be explained. It basically describes you which sources we use for ArmTrustedFirmware (part of  all(most?) ARM64 boards during boot. U-boot (before the kernel fires up) and which kernel sources will be used for default (often a BSP Kernel), next (mostly a vanilla kernel) and dev (mostly a kernel close to mainline - for rockchip64 for example this is a kernel based on 4.20). some tweaks needed to build an image (e.g. different SoCs expect the u-boot binary on a clear defined place inside the SD-Card for example here: dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none >/dev/null 2>&1 ) tweaks which are needed to boot up the board (e.g. rockchip needs a few binaries and it depends on which rockchip SoC, (sometimes also ramspecific) you use to boot up a board - rockchip64 is for rk3328 and rk3399 and they use different binaries) some family_tweaks here to enable debug console etc. (boardspecific tweaks are also here with some if statements to keep those changes separated from the others). To do changes here or to create such a file from plain (for a new boardfamily) you might need some more experience but it's worth to have a look at it (especially to check which sources we use). The rest of config is currently not that important.

  • config-default.conf (shows up after you build an image for the first time): this file will be important but since this post here gets anyways too long I try to explain it in the next days (it deserves to have it's own day) :D

  • lib: the build-script is not only one big bash-script it's splittened into different ones. In the beginnings you (hopefully) don't need to change something in them but cause the script isn't everywhere 100% clean (we've to be pragmatic here + different people have different opinions how stuff should be solved) it's worth to try to understand how random part of the script work (needs knowledge in bash and definitively not learned within a few hours - you need some background this grows over time)

  • output: that's where your kernel config (if you decide for Show a kernel configuration menu before compilation - would also need it's own post), debs (debian packages built during compilation, e.g. needed for sending kernelupgrades via apt upgrade), debug (also something for a further tutorial - you'll have a lot of fun with this folder during development :lol:) images (the finally compiled images if nothing fails) patch (will be explained in the follow up, but that's most of the work devs do here.. :D - e.g. if we fix something inside a kernel or u-boot etc. a patch is automatically generated this is then moved to the appropriate patch folder and part of the buildscript)

  • packages:  blobs we've to deliver (e.g. to boot up a board), bsp (board support package - I also call non vanilla kernels bsp kernels, it has similarities but it's not the same - some boards need special configurations, e.g the bananapi r2 which has 5x GbE has here some configuration files to bring up all it's interfaces), tools (never worked with, ask someone else :D ) extras-buildpkgs for packages we deliver to get the enhanced functionality ( also not needed to understand fully in the beginnings - wouldn't call myself an expert on this part.. :D )

  • patch: if you generate a patch for kernel or u-boot and you want that others can use it as well place it here in the right folder, create a pull request to armbian and we'll get it. The structure is 'relatively' simple splitted into kernel, u-boot and atf (you won't patch atf soon.. :D ) for the kernel then splitted into boardfamily-branch (default,  next & dev - for the rockpi this means rockchip64-default and rockchip64-dev is of interest). For u-boot it's mostly u-boot-boardfamily (sometimes we have two branches for u-boot, e.g. the time we switch from a out of tree u-boot to upstream or we need different u-boot sources. not that often here u-boot-rockchip64-dev is of interest for the RockPi)

  • userpatch: the same than patches but for stuff you don't submit back to our tree (e.g. you can place your patch there if for whatever reasons it's not accepted by armbian - e.g. if it breaks other boards)

now you got an brief overview how much you'll have to learn until you understand it fully and in the next days I might partly explain how to use it.. If you can't wait reading more.. there you go:

https://forum.armbian.com/topic/6-how-to-build-my-own-image-or-kernel/?page=6&amp;tab=comments#comment-65998

https://forum.armbian.com/topic/7296-bananapi-r2-csc-mt7623-as-new-boardfamily/

 

have fun. :P

4
chwe

chwe

Posted
  • Author
Posted

Talking about config-default.conf and a bit of my workflow (others might do it different and I do boardbring up, kernel-patching by accident not by training - I normally do in science not in computes stuff :ph34r::lol:) for patching today:

  Reveal hidden contents

actually the first line describes everything you need here... :lol: just read the docs and you'll get most of the things well described. For simplicity we use the menu which opens by starting the script with sudo ./compile.sh without any additional flags (docs explain also how to do it with flags but that not really needed, it's just faster than searching your board in the menu.

LIB_TAG becomes important cause it defines on which branch you build images (e.g. normally you do it on master when you just want to build the newest image for your board with armbians settings - as a developer who doesn't commit directly into armbians master, the workflow differs a bit and other branches than master become more important).

 

I assume that you've a GitHub account and already forked the project online. If you look at my masters tree (https://github.com/chwe17/build) it's mostly a few commits behind armbians masters tree (depends when I last synced my master with armbians - github explains perfectly how to sync a fork and how to add another remote) but it's never commits ahead of armbians master I do want to have the same git history in master as armbian has it just makes things simpler (git merge will always works without issues :P ).. On my current buildmachine I cloned directly my fork for building and not armbians. In case you have cloned the original and you don't want to loose all your stuff in cache (e.g. compilers which just need a bunch of time) you'll have to delete the remotes and set origin to your fork (google will help you on this one) and upstream to https://github.com/armbian/build.git (or dealing everytime with the proper commands when push stuff online - if you're not a git-ninja :ph34r: just set origin to your fork and upstream to armbians). Example: 

chwe@chwe-HP:~/armbian/build$ git remote -v
origin	https://github.com/chwe17/build.git (fetch)
origin	https://github.com/chwe17/build.git (push)
upstream	https://github.com/armbian/build.git (fetch)
upstream	https://github.com/armbian/build.git (push)

 

First make sure that (at least) your local master branch is synced with armbians (due to set origin to your fork, this doesn't happen automatically during build! it will only sync it with your fork which is quite sure some commits behind armbians):

  1. check on which branch you are. We will do all the development in features branches not in master! So you might be on a different one from your last build: 
    chwe@chwe-HP:~/armbian/build$ git branch
* master
  mt7623
  r2_gmac

     

  2.  in this case everything is fine but it happened quite often in the beginnings that I was on one of my features branches which then ended in a mess (I've some features branches which have a lot of changes compared to armbians master)... :lol:
  3. if you're on a features branch make sure you've a clean working tree before you switch. git status can help you here to ensure your tree is clean. Example for a clean one: 
    chwe@chwe-HP:~/armbian/build$ git status
On branch mt7623
Your branch is up to date with 'origin/mt7623'.

nothing to commit, working tree clean

    or a dirty one: 

    chwe@chwe-HP:~/armbian/build$ git status
On branch mt7623
Your branch is up to date with 'origin/mt7623'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	some_random_fancy_shit_i_did_in_my_features_branch.txt

nothing added to commit but untracked files present (use "git add" to track)

    (either with git stash or git add -A && git commit see git manuals what might be appropriate here - I prefer often to commit stuff if it's (partly) working and stash only when I'm quite sure I'll switch back to the features branch soon, commit messages can help you sometimes if you don't remember the rational behind a changes you did a few weeks back on features which need a bit more time to develop ISP1 driver on rk3288 was a feature I tried over weeks and failed more than once :lol: - btw. got never merged into master for good reasons). If the tree is clean switch to master with git checkout master!

  4. now we sync our master with armbians master (and push it online to our fork as well, example in spoiler): 

    git fetch upstream
git merge upstream/master
git push
      Reveal hidden contents

    if you visit your fork online this should be visible: This branch is even with armbian:master.

  5. Let's create a features branch for our funny new feature locally and on remote (git checkout -b branchname && git push -u origin rockpi_tutorial): 

    chwe@chwe-HP:~/armbian/build$ git checkout -b rockpi_tutorial
Switched to a new branch 'rockpi_tutorial'
chwe@chwe-HP:~/armbian/build$ git push -u origin rockpi_tutorial
Username for 'https://github.com': chwe17
Password for 'https://chwe17@github.com': 
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: Create a pull request for 'rockpi_tutorial' on GitHub by visiting:
remote:      https://github.com/chwe17/build/pull/new/rockpi_tutorial
remote: 
To https://github.com/chwe17/build.git
 * [new branch]        rockpi_tutorial -> rockpi_tutorial
Branch 'rockpi_tutorial' set up to track remote branch 'rockpi_tutorial' from 'origin'.

    now config-default.conf and especially LIB_TAG becomes important. We tell the build-script now that by default we want to build images on our new features branch. So change LIB_TAG="master" to LIB_TAG="rockpi_tutorial" with your favorite editor. Cause we go to create a patch, change it to yes as well CREATE_PATCHES="yes".

In the next days I'll have a look if there's an easy but meaningful example of patching something for RockPi including the pull request to bring it back to armbian. I'm quite confident we'll find something in the device tree to fix... :lol::ph34r:

 

The reason I work with features branches is quite simple.. In case my random ponny feature doesn't make it in the pull request (maybe the change isn't that smart or it breaks something I didn't consider) and therefore doesn't get merged into armbians masters I simply can delete my branch or let it collect dust but I don't have to do anything in my masters branch (e.g. 'rewrite' the git history to have it even with armbians for my next features branch which is hopefully better than the one which didn't make it - it's just painful to clean up a messed up masters to get it back to the githistory of armbians - believe me, I did it more than once when I wasn't that familiar with git :lol::ph34r: - as said in the starter, we all didn't start as git-kernel-u-boot-userspace ninjas :ph34r:). On a features branch this doesn't happen. :) delete it or let it collect dust once you don't need it anymore. 

1
JMCC

JMCC

Posted
Posted

RK3399 media testing script released, in case someone makes the board work and wants to give it a try:

 

 

Dante4

Dante4

Posted
Posted

Thanks @chwe for your posts!

 

 

  On 1/10/2019 at 1:44 PM, JMCC said:

 

RK3399 media testing script released, in case someone makes the board work and wants to give it a try:

 

 

Expand  

Well. Official Armbian not really ready yet and Radxa Armbian is Debian Stretch,  but thanks for it, that's really helpful for just user 

 

 

 

JMCC

JMCC

Posted
Posted

Anybody knows if the Raxda fork of our build script is public? I didn't find it in their Github.

 

I want to build a Bionic image.

chwe

chwe

Posted
  • Author
Posted

As promised we prepare a little patch for our RockPi... :)Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:

git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)

 

  Reveal hidden contents

 

 

It's not allays that much.. :P but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.

https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284 

	gpio-leds {
		compatible = "gpio-leds";


		user-led1 {
			gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>;
			linux,default-trigger="heartbeat";
			default-state = "on";
		};


		user-led2 {
			gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>;
			linux,default-trigger="heartbeat";
			default-state = "on";
		};

If we don't know what we can do with those we can look into documentation:

https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt

and from there:

https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt

 

you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...

so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes") 

CREATE_PATCHES="yes"                    # wait that you make changes to uboot a$
BUILD_ALL="no"                          # cycle through available boards and ma$
                                        # set KERNEL_ONLY to "yes" or "no" to b$

BSPFREEZE=""                            # freeze armbian packages (u-boot, kern$
INSTALL_HEADERS=""                      # install kernel headers package
LIB_TAG="rockpi_tutorial"                       # change to "branchname" to use$
CARD_DEVICE="/dev/mmcblk0"                              # device name /dev/sdx $
EXPERT="yes"

 

if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.

ATF: 

[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ]
[ warn ] Press <Enter> after you are done [ waiting ]
[ warn ] No changes found, skipping patch creation

u-boot: 

[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ]
[ warn ] Press <Enter> after you are done [ waiting ]

okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):

  Reveal hidden contents

as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:

  Reveal hidden contents

as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel: 

[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ]
[ warn ] Press <Enter> after you are done [ waiting ]

/home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts

keep in mind.. we've to change it in the LED node and the pinctrl node..

 

in build/output/patch we get two patches:

u-boot-rockchip64-dev.patch:

  Reveal hidden contents

and for the kernel: (kernel-rockchip64-dev.patch)

  Reveal hidden contents

now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right.. :P

as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..

  Reveal hidden contents

hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..

means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.

U-boot: 

diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts
index 5d73ce5..5574e9b 100644
--- a/arch/arm/dts/rk3399-rockpi4b.dts
+++ b/arch/arm/dts/rk3399-rockpi4b.dts
@@ -65,14 +65,9 @@
 		status = "okay";
 		compatible = "gpio-leds";

-		power-led {
-			label = "power";
-			gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
-		};
-
-		standby-led {
-			label = "standby";
-			gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+		system-status {
+			label = "status";
+			gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
 		};
 	};

Kernel: 


diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
index 7f10da2a8..1d4721dcc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
@@ -140,20 +140,15 @@
 	};

 	leds {
+		status = "okay";
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
-		pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>;
-
-		work-led {
-			label = "work";
-			default-state = "on";
-			gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
-		};
+		pinctrl-0 = <&status_led_gpio>;

-		diy-led {
-			label = "diy";
-			default-state = "off";
-			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+		system-status {
+			label = "status";
+			gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
 		};
 	};

@@ -643,12 +638,8 @@
 	};

 	leds {
-		work_led_gpio: work_led-gpio {
-			rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-
-		diy_led_gpio: diy_led-gpio {
-			rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+		status_led_gpio: status_led_gpio {
+			rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};

Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:

uboot: 

[ o.k. ] * [l][c] add-board-renegade.patch 
[ o.k. ] * [l][c] add-board-rockpi4b.patch 
[ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch 
[ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch 
[ o.k. ] * [l][c] board-renegade-updates.patch 
[ o.k. ] * [l][c] enable-DT-overlays-support.patch 
[ o.k. ] * [l][c] fix-rockpi4b-led.patch

and kernel: 

[ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch 
[ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch 
[ o.k. ] * [l][c] add-board-rockpi4b.patch 
[ o.k. ] * [l][c] add-fusb30x-driver.patch 
[ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch 
[ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch 
[ o.k. ] * [l][c] fix-rockpi4b-led.patch 
[ o.k. ] * [l][c] fix-rockpro64-emmc.patch 
[ o.k. ] * [l][c] fix-spi1-flash-speed.patch 
[ o.k. ] * [l][c] general-add-overlay-compilation-support.patch 
[ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch 
[ o.k. ] * [l][c] general-packaging-4.17-dev.patch 
[ o.k. ] * [l][c] general-rockchip-overlays.patch 
[ o.k. ] * [l][c] nanopi4-dts.patch 
[ o.k. ] * [l][c] orangepi-rk3399-dts.patch 
[ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch 
[ o.k. ] * [l][c] renegade-enable-usb3.patch 
[ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch 
[ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch 
[ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch 
[ o.k. ] * [l][c] unlock-temperature.patch

seems that everything is okay. So it's time to bring them back to armbian. :) Let's check our repo with git status: 

chwe@chwe-HP:~/armbian/build$ git status
On branch rockpi_tutorial
Your branch is up to date with 'origin/rockpi_tutorial'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch
	patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch

nothing added to commit but untracked files present (use "git add" to track)

there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push 

chwe@chwe-HP:~/armbian/build$ git push
Username for 'https://github.com': chwe17
Password for 'https://chwe17@github.com': 
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done.
Total 9 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), completed with 4 local objects.
To https://github.com/chwe17/build.git
   a156fddf..bb63ed6d  rockpi_tutorial -> rockpi_tutorial

https://github.com/chwe17/build/tree/rockpi_tutorial

our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:

https://github.com/armbian/build/pull/1236

 

You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it. :)

 

Edit: this post was written 'on the fly'.. :P If something isn't clear, just let me know.. and I'll try to explain it better.

Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer. :)

2
chwe

chwe

Posted
  • Author
Posted

for whatever reason compiling ATF fails from time to time.. 

3.2.1.make -C plat/rockchip/rk3399/drivers/m0 BUILD=/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/build/rk3399/debug/m0
make[1]: Entering directory '/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/plat/rockchip/rk3399/drivers/m0'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/plat/rockchip/rk3399/drivers/m0'
make: Nothing to be done for 'bl31'.
out:trust.bin
E: [mergetrust] filter_elf ./build/rk322xh/debug/bl31/bl31.elf file failed
merge failed!
[ error ] ERROR in function compile_atf [ compilation.sh:83 ]
[ error ] ATF file not found [ trust.bin ]
[ o.k. ] Process terminated

the sources with ATF were still there.. but int fails.. the merge looks like doing it for the wrong soc? someone has a clue?

 

Edit: if you build an image for the rockpro first.. it normally doesn't break..

mitag

mitag

Posted
Posted

The RockPi does not boot Armbian Stretch from the inserted SD card if an eMMC is installed at the same time. As soon as I remove the eMMC it works. An image of radxa boots even if eMMC is installed. This behavior irritates me a bit, is that normal?

 

Image on the SD card: Armbian_5.73.190128_Rockpi-4b_Debian_stretch_dev_4.20.0

I hope I'm right here if I find something while testing the nightly development branch.

chwe

chwe

Posted
  • Author
Posted
  On 2/1/2019 at 7:11 PM, mitag said:

An image of radxa boots even if eMMC is installed. This behavior irritates me a bit, is that normal?

Expand  

probably not.. But you have at least to provide a bootlog from serial console to get a clue where it messes.. RockPi is in early stage of board bring up (wip). Bugs must be expected..

 

  On 2/1/2019 at 7:11 PM, mitag said:

I hope I'm right here

Expand  

nope, therefore moved to the rockpi thread..

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept