Instructions to build U-Boot on macOS

[Instructions to build U-Boot on macOS]

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?

[Instructions to build U-Boot on macOS]

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.