Jump to content

xdev20

Members
  • Content Count

    2
  • Joined

  • Last visited

  • Days Won

    2

Posts 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?

    • Like 1

  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.

    • Like 2
×
×
  • Create New...