GPIO in /sys/class/leds/

post the output of make -j1 V=s it shows the most likely cause of the error

-j1 V=s takes a whole lot of time and eventually throws up the same error.
Doesn't proceed beyond AR drivers/built-in.o.

Might try V=sc

Also, copying the output into a "code" box here with the </> editor button would be helpful. It's not easy to read that screenshot.

The output of make -j1 V=sc

Github_Gist

Pastebin doesn't allow larger than 512KB.

scripts/Makefile.lib:317: recipe for target 'arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dtb' failed

check that file at that line

Unable to find such file or directory structure located in OpenWrt build directory.

Checked with raspberry/linux sources:

  mkdir -p arch/arm64/boot/dts/broadcom/ ; aarch64-openwrt-linux-musl-gcc -E -Wp,-MD,arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.d.pre.tmp -nostdinc -I./scripts/dtc/include-prefixes -undef -D__DTS__ -x assembler-with-cpp -o arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.dts.tmp arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dts ; ./scripts/dtc/dtc -O dtb -o arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dtb -b 0 -iarch/arm64/boot/dts/broadcom/ -i./scripts/dtc/include-prefixes -@ -H epapr -Wno-unit_address_vs_reg -Wno-simple_bus_reg -Wno-unit_address_format -Wno-pci_bridge -Wno-pci_device_bus_num -Wno-pci_device_reg  -d arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.d.dtc.tmp arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.dts.tmp ; cat arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.d.pre.tmp arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.d.dtc.tmp > arch/arm64/boot/dts/broadcom/.bcm2710-rpi-3-b.dtb.d
scripts/Makefile.lib:317: recipe for target 'arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dtb' failed

You won't find arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dtb because the error message is that the build system was unable to make that file.

The problem is likely somewhere in your DTS. From the looks of things and the absence of a location of an error in a file, I would guess it's syntactically correct, but logically "wrong".

Can you successfully build without any changes?

Edit: Since I don't see a DTS for the device under target/linux, it looks like when the time comes, you'll need to patch it, rather than edit it.

Edit: Confirmed that the upstream is used

build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/linux-4.14.102/arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dts

which looks like it immediately includes

build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/linux-4.14.102/arch/arm/boot/dts/bcm2710-rpi-3-b.dts

"Stock" builds cleanly here, without any changes.

1 Like

Yes. The original sources compile without any issues.

I tried compiling with many adjustments in the DTS. Also tried to add an overlay.

make target/linux/compile succeeds without any issues.
make world fails. The problem is with the RaspberryPi3 itself. It uses a different type of addressing for the GPIOs.

I'll try it out with an original Raspberry Pi B.

UPDATE:

I tried the modification with an Orange Pi R1 and it worked perfectly.
Had to modify the up-stream linux kernel DTS.

The issue was with RaspberryPi using a different addressing scheme for its extended gpios.

2 Likes

Maybe posting a mini snippet to highlight the key scheme difference would help others?

1 Like

For the OrangePi R1, there was no DTS inside the OpenWrt sources.
Upon observing the compilation output, I was sure that it used upstream Linux sources.

I didn't spend time trying to make a patch file. (i had no idea how to do that)

I browsed to the dl folder, extracted linux-kernel tar file, browsed to the DTS file of OrangePi R1 and added the segment for the leds there itself. Recompressed and replaced the original file at dl directory.

after that.

make target/linux/clean
make -j5 target/linux compile V=s

It compiled without any errors.

make -j5 V=sc

Installed the build, connected leds to the gpios through a resistor, configured trigger and it worked perfectly.

Modifications at /arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts

leds {
		compatible = "gpio-leds";

		pwr_led {
			label = "orangepi:green:pwr";
			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
			default-state = "on";
		};

		status_led {
			label = "orangepi:red:status";
			gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
		};

		act_led {
			label = "orangepi:red:act";
			gpios = <&pio 0 6 GPIO_ACTIVE_HIGH>;
		};

		wan_led {
			label = "orangepi:red:wan";
			gpios = <&pio 0 12 GPIO_ACTIVE_HIGH>;
		};
	};
2 Likes

It isn't the most obvious process if you haven't worked with quilt before, but it isn't terrible once you get the hang of it. https://openwrt.org/docs/guide-developer/patches

Basically the workflow is, once you've gotten quilt installed and configured, starting at the root of the build system:

  • make target/linux/{clean,prepare} V=s QUILT=1 # get the source ready for modification (V=s can be omitted)
  • pushd build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx/linux-4.14.99 # move into the top-level kernel sources (your path is probably different)
  • For a new patch
    • quilt push -a # apply all existing patches
    • quilt new platform/NNN-name-of-your-special-patch # create a new target-specific patch
  • For an existing patch
    • quilt push platform/NNN-name-of-your-special-patch # move up to "your" patch
  • quilt edit some/file/that/needs/to/be/changed # tell quilt to "remember" that file as it is now
  • (do your edits)
  • quilt refresh # capture the changes in that file within the quilt system
  • popd # back to the root of the build tree
  • make target/linux/update package/index V=s # Convert the quilt changes from above into a "real" patch

From there, you can add/update the file in your git repo, make, or whatever you desire.

2 Likes

Thanks for the update, and congrats on sticking at it and working it out!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.