Beginner question on .dtb

[daniejd]

Let me start by saying thank you all for the great work, it is appreciated! So a bit of info first.

 

board: firefly rk3399-pc pro ( yeah I know it’s old, but so am I!)

os: armbian Debian trixie

kernel: 6.18.35

 

Bear with me, last time I touched Linux, lilo and xfree86 were things…

 

I installed the community supported rk3399-firefly as I didn’t find a better match for the pro. Most of the hardware worked with the major exception of the audio. No problem, the rk3399-roc-plus.dts had the correct audio for the board all I needed to do was switch the audio portion into the rk3399-firefly.dts  (though other aspects including just booting stopped me from directly switching to the plus dts). I mistakenly cloned and compiled from the mainline (I put the ‘no!’ In noob). It of course didnt work. Next I cloned and compiled (without changing anything) from the armbian repository. Again it would not boot.

 

So here is the embarrassing question. Where is the repository that contains the dts files that are actually used to build the dtb files in the active images? My last try was github.com/armbian/rockchip.git .

 

Im pretty sure I’m cloning, compiling and switching the dtb correctly, just can’t find the right source material!

 

Again, thank you in advance.

 

-J

Edited August 2 by daniejd

[eselarm]

I had a look what this brand/board is about and it seems the community has only 1 variant in the build database and pre-installed images only mainline kernel based. So I think you already digged quite deep into it and at the point that you are more expert than what is available. So it would mean you add the board to Armbian as also a community member and since it is mainline, it would mean just adding it to mainline Linux kernel,  see Armbian docs how to add a board.

 

For reference, latest kernel is here:  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip

So upstream linux instead of downstream rockchip what is here:

https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip

or to some other repo (Firefly, vendor?)

Where you got that rk3399-roc-plus.dts from?

 

But more important:

7 hours ago, daniejd said:

Again it would not boot.

is just very little info. What went wrong?

 

You need UART serial console/debug cable output shared here and also how did you clone and compile? e.g. what .config is used, etc.

 

If I would have this board, I certainly cannot reproduce your issues or compare potential non-booting symptoms with yours, so try to provide all that it needed so someone else can do and see then same as you.

[daniejd]

Thank you! At this point I am just trying to reproduce the rk3399-firefly.dtb that is currently available in the weekly images. (I am new to this and it gets confusing with multiple repositories and dts that are different in them, though it is probably me just not knowing where to look.) And to further obscure things firefly chose the single worse naming conventions for their boards! I will give the links you supplied a try.

[daniejd]

Those links were a no go. They compiled and behaved exactly like the previous failed dtb. For example the current working dtb from the image is 85k. From the mainline, it compiles to 65k, and silently fails (getting to the uart is a bit of a pia, that’s why I am only trying to reproduce what is already working). From the armbian tree it compiles to 97k and also fails silently, though the power led works.

 

This is compiling on the board itself. No warnings or errors. A basic clone>makeconfig>make.

 

The image dtb works, but I can’t reproduce it.

 

-J

[eselarm]

You should use Armbian Build to (re)produce images. That is what Armbian is about. Read docs. You will have sources all pulled from github on your local computer. It is even listed noadays per board

https://armbian.com/boards/firefly-rk3399

[daniejd]

Im sorry Im not following. https://armbian.com/boards/firefly-rk3399 Is what I have and what is mostly working. All I want to do is correctly reproduce the dtb used in those images from the source.
 

If I use Armbian build won’t it create a kernel etc? And I don’t think my board could handle that.

 

At this point im assuming that Armbian build applies something to the dtb other than whats listed in the dts. No idea.
 

I really don’t want to decompile the working dtb, and try and hack my way through all those hex addresses, but unless I can reproduce the working dtb, that may be the only option.

[eselarm]

You need a build computer, as I said read docs.

 

If you only want to change .dtb, decompile it, change  the .dts text, then recompile. see 'man dtc'

[daniejd]

I do appreciate the help, but I believe we are just going around in circles. I’ll mark it as the solution to close the thread. Thank You.

 

-J

[SteeMan]

As was stated you need to read the docs and understand the Armbian build system.  Basically it starts with the generic kernel source then applies a series of patches.  The patches add/modify that generic code with changes that Armbian adds (changes that are not in mainline kernel source).  Then the build applies these patches (plus any user supplied patches) to the source and then builds from that.  

So you can run a build and then look at the cached source after patching and see the source dts in your case.

It isn't hard but does require some effort and digging.

[daniejd]

Sorry it wasn’t clear to me that the ONLY way to generate a single dtb from source was to go through the entire Armbian custom build process. I was aware that was one possible route, though in my case it seemed overkill. Either way I am grateful you guys got me as far as you did, thank you!

 

-J

[daniejd]

https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-7.2/board-firefly-rk3399-dts.patch I assume you mean something like this?

 

Thank you both for the explanation. While I understood the concept I really had no idea the layers of patches or the fact that no clean source (patch applied) existed in the repository.

 

I decided to decompile and hack the hex (while the suggestion of using armbian build seems simple, it really isn’t in my situation). It seems promising, not working but the card is now correctly recognized and getting power, so a step closer…

 

Thank you both for you patience, Caio.