Spontaneous numlock

[ab1jx]

I took that DTC out and installed this one: https://github.com/dgibson/dtc  I still get the same error

Code:

/usr/local/bin/dtc rk3399-pinebook-pro.dts
Error: rk3399-pinebook-pro.dts:9.1-9 syntax error
FATAL ERROR: Unable to parse input tree

That's using the dts from https://git.kernel.org/pub/scm/linux/ker...ok-pro.dts  I poked around there and found a blob link that got me just plain text so I didn't have to copy off the page and get formatting junk in it.

dtc I used the make NO_PYTHON=1 option on and ended up with these files:

Code:

convert-dtsv0
dtc
dtdiff
fdtdump
fdtget
fdtoverlay
fdtput

I chewed him out for not having line numbers in his error messages: https://github.com/dgibson/dtc/issues/48

[dsimic]

Actually, you need to run the .dts file through the C preprocessor first, as decribed here in more detail.

[ab1jx]

I'm getting deeper and deeper.  I don't suppose I could just do cpp myfile.dts?  Kidding mostly.  This makefile is one I changed slightly from the linked example.  I suspect it's trying to bring in stuff I don't need/want.

Code:

SRCARCH = arm

DTC = dtc
DTCFLAGS = -b 0
dtc_cpp_flags  = -x assembler-with-cpp -nostdinc        \
                -I $(srctree)/arch/$(SRCARCH)/boot/dts        \
                -I $(srctree)/arch/$(SRCARCH)/boot/dts/include \
                -undef -D__DTS__

DTCINCLUDES = -i $(srctree)/arch/$(SRCARCH)/boot/dts -i $(srctree)/arch/$(SRCARCH)/boot/dts/include

%.dtb: %.dts
cpp $(dtc_cpp_flags) < $< | $(DTC) $(DTCINCLUDES) -I dts -O dtb $(DTCFLAGS) -o $@ -

#all: isocfpga_cyclone5_DE1-SoC.dtb
all: rk3399-pinebook-pro.dtb

When I run make it looks like it wants most of a kernel source tree.  Which one?  Should I just try to build a whole kernel while I'm at it?

Code:

cpp -x assembler-with-cpp -nostdinc -I /arch/arm/boot/dts -I /arch/arm/boot/dts/include -undef -D__DTS__ < rk3399-pinebook-pro.dts | dtc -i /arch/arm/boot/dts -i /arch/arm/boot/dts/include -I dts -O dtb -b 0 -o rk3399-pinebook-pro.dtb -
<stdin>:9:41: error: no include path in which to search for dt-bindings/input/gpio-keys.h
<stdin>:10:49: error: no include path in which to search for dt-bindings/input/linux-event-codes.h
<stdin>:11:33: error: no include path in which to search for dt-bindings/pwm/pwm.h
<stdin>:12:32: error: no include path in which to search for dt-bindings/usb/pd.h
<stdin>:13:37: error: no include path in which to search for dt-bindings/leds/common.h
<stdin>:14:10: fatal error: rk3399.dtsi: No such file or directory
compilation terminated.
Error: <stdin>:8.9-10 syntax error
FATAL ERROR: Unable to parse input tree
make: *** [Makefile:13: rk3399-pinebook-pro.dtb] Error 1

I've built kernels before, mostly for the BSDs.  A couple Linux ones.  Not in 10-20 years.  Or can I just get this dt-bindings subdir and that's all I need? Actually I may have parts of it in different places if I use locate to find the files mentioned. I have a u-boot source dir a couple months old, some is in there, looks like most of it.

[dsimic]

Alright, let's see how deep is the rabbit hole.

Preprocessing requires the .dtsi files and the .h files, which are found in the arch/arm64/boot/dts/rockchip and include/dt-bindings directories inside the Linux kernel source, respectively.  Cobbling everything together should be rather manageable.

[wdt]

Clearly neither of you have tried to "hack" an android TV box
This often require trying different dtb files
Do understand, a dtb file is just formated text, not code
As long as it is for the right architecture it may boot
Well, android dtb's have the partitioning in kernel cmd line,,
and PBP needs special treatment for the display
But you could try any other distros rk3399pinebookpro dtb
For that matter dtc is not a complicated compiler/decompiler
When decompiled you lose some symbolic names (for the jumps/address) but the sections are still clear
There is a switch to make it alphabetical (when decompiled), makes the diffs easier

[dsimic]

Please, keep in mind that no real "hacking" is going on in this thread, in the sense of having no need to try out different device tree configurations or tweaks. The desired, final version of the device tree is well known, and we're just working on getting it through, with some pleasant banter along the way.

[ab1jx]

I gave up and copied in the dtb from Armbian which is 80k instead of the 60k one I was using.  Maybe I'll try a Manjaro one someday.  It's just not that important and I've sunk enough time into it.

That didn't do anything for my numlock key so I tried the dtb from Manjaro, that doesn't either.  But oddly enough Fn-Print Screen and Fn-Pause both toggle the NumLock.  Which brings up the question: do the ANSI and ISO keyboard versions have different dtb files?  The Manjaro install asks which keyboard I have but I grabbed the rk3399-pinebook-pro.dtb file anyway.  Still have it in place.

The Manjaro dtb is 88924 bytes, the Armbian 80978, what I started  with is 60731.  They all work to varying degrees.  Not sure how to compare but both the bigger ones populate more device names in amixer I think.

[dsimic]

Which brings up the question: do the ANSI and ISO keyboard versions have different dtb files?  The Manjaro install asks which keyboard I have but I grabbed the rk3399-pinebook-pro.dtb file anyway.  Still have it in place.

No, the device tree specification for the PineBook Pro is the same for both keyboard types.

The Manjaro dtb is 88924 bytes, the Armbian 80978, what I started  with is 60731.  They all work to varying degrees.  Not sure how to compare but both the bigger ones populate more device names in amixer I think.

The size difference is there because Manjaro and Armbian use the current device tree specification, to which Majaro also applies some patches, while the one you used originally was old and incomplete.  Has the update of the .dtb file made the built-in speakers automatically turn off upon plugging in the headphones?

[ab1jx]

I'll try that, I've been only checking the numlock key.

Which still doesn't work booted from Manjaro.

[dsimic]

Did I get you right that NumLock doesn't work at all on your PineBook Pro running Manjaro ARM?