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.
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.
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.
Maybe posting a mini snippet to highlight the key scheme difference would help others?
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>;
};
};
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 patchesquilt 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 systempopd
# back to the root of the build treemake 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.
Thanks for the update, and congrats on sticking at it and working it out!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.