Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by xdev20

  1. I was a bit busy lately, but after some investigation I managed to find the reason some device trees failed to compile. I realized that "make" invokes the part that causes the error like this in a linux VM: (cat ../arch/arm/dts/rk3036-sdk.dts; echo '#include "rk3036-sdk-u-boot.dtsi"') > arch/arm/dts/.rk3036-sdk.dtb.pre.tmp; while in macOS it is invoked like this: (cat ../arch/arm/dts/rk3036-sdk.dts; echo '\#include "rk3036-sdk-u-boot.dtsi"') > arch/arm/dts/.rk3036-sdk.dtb.pre.tmp; It seems to be caused by the hash character having a special meaning in shell. I managed to fix, and here is the patch: diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 12d1123a07..9e419a0890 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -6,6 +6,8 @@ asflags-y += $(EXTRA_AFLAGS) ccflags-y += $(EXTRA_CFLAGS) cppflags-y += $(EXTRA_CPPFLAGS) ldflags-y += $(EXTRA_LDFLAGS) + +hash = \# # # flags that take effect in sub directories @@ -308,7 +310,7 @@ quiet_cmd_dtc = DTC $@ # Modified for U-Boot # Bring in any U-Boot-specific include at the end of the file cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ - (cat $<; $(if $(u_boot_dtsi),echo '\#include "$(u_boot_dtsi)"')) > $(pre-tmp); \ + (cat $<; $(if $(u_boot_dtsi),echo '$(hash)include "$(u_boot_dtsi)"')) > $(pre-tmp); \ $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \ $(DTC) -O dtb -o $@ -b 0 \ -i $(dir $<) $(DTC_FLAGS) \ I tested the patched version in my macOS machine and a linux VM and I was able to compile successfully in both (with appropriate KCFLAGS). Is it possible to get this merged to the main repo in GitHub? Should I open a PR?
  2. Hi everybody, Recently, I have been trying to run some bare metal code on my Tinker Board 2. I managed to compile ARM Trusted Firmware - A successfully with these commands: % git clone https://github.com/ARM-software/arm-trusted-firmware.git tf-a % cd tf-a % export CROSS_COMPILE=~/Developer/Toolchains/aarch64-none-elf/bin/aarch64-none-elf- % make PLAT=rk3399 After that, I tried to build U-Boot with these commands (the CROSS_COMPILE variable is set from previous commands): % git clone https://github.com/TinkerBoard2/u-boot.git uboot % cd uboot % export BL31=../tf-a/build/rk3399/release/bl31/bl31.elf % export KBUILD_OUTPUT=build % make tinker2_defconfig % make This, unfortunately failed with this error: DTC arch/arm/dts/rk3036-sdk.dtb Error: arch/arm/dts/.rk3036-sdk.dtb.pre.tmp:77.1-10 syntax error FATAL ERROR: Unable to parse input tree I tried to fix the problem, and I thought removing 'rk3036-sdk.dtb' from 'arch/arm/dts/Makefile' could work since it seemed to be the device tree of another board that I was building for, which happened to be ill formed. That made the problem disappear, but the same thing happened for 'rk3368-lion.dtb', 'rk3368-sheep.dtb' and a couple of other device trees. I removed them all (7 in total) and the build finally succeeded. I then created a GPT disk image, with a single FAT32 partition with my code compiled, in it. The partition started at sector 18405, so there should have been plenty space for U-Boot. I verified with gdisk that my disk image is not corrupt, so that is clearly not the problem. I tried writing U-Boot into the SD card with the instructions in https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip and https://github.com/u-boot/u-boot/blob/master/doc/board/rockchip/rockchip.rst. Packaging with rockchip miniloader did kind of work, but it printed some unusual characters (Chinese or Japanese?) and a lot of diamonds with single question mark in them at the beginning, and I had to set the baud rate to 120000 to view the output properly. Using U-Boot SPL and U-Boot TPL + SPL only printed one diamond with a question mark in it. I also tried the method provided as an answer to this post, but that did not work, probably because it was for eMMC. I used this command to see if it worked: minicom -D /dev/cu.usbserial-1440 -b 115200 -o I connected my serial to USB cable as instructed in this post I am sure my board is not broken as I was able to run the official Debian image without U-Boot printing any weird characters or problems with baud rate. I wonder, if any Tinker Board engineers could share how U-Boot is built when preparing the official image. Any help is appreciated.
  • Create New...