[BPI-R64] uboot

frank-w · September 26, 2019, 8:28am

ah ok, seems to work…now i get linking-errors where i have removed the weak-lines…

  LD      u-boot
arch/arm/lib/built-in.o: In function `clbss_l':
/media/data_fast/bpi/uboot/u-boot/arch/arm/lib/crt0.S:110: undefined reference to `coloured_LED_init'
/media/data_fast/bpi/uboot/u-boot/arch/arm/lib/crt0.S:111: undefined reference to `red_led_on'
arch/arm/lib/built-in.o: In function `bootstage_mark_name':
/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:356: undefined reference to `show_boot_progress'
/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:356: undefined reference to `show_boot_progress'
/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:356: undefined reference to `show_boot_progress'
common/built-in.o: In function `bootstage_mark_name':
/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:356: undefined reference to `show_boot_progress'
common/built-in.o: In function `bootstage_mark':
/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:344: undefined reference to `show_boot_progress'
common/built-in.o:/media/data_fast/bpi/uboot/u-boot/include/bootstage.h:344: more undefined references to `show_boot_progress' follow

ah, ok, copy empty functions to mt7622_evb.c…now compile works with gcc7

BPI-R64> version

U-Boot 2014.04-rc1-00027-g2c83f9c241-dirty (Sep 26 2019 - 10:33:50)
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
GNU ld (GNU Binutils for Ubuntu) 2.30
BPI-R64>

for gcc8 i need a compiler-gcc8.h, i have not yet found any with google…only other versions…but i have found one in my kernel-repo compiles fine and seems to work

BPI-R64> version

U-Boot 2014.04-rc1-00028-ge7e4914e34-dirty (Sep 26 2019 - 10:43:27)
arm-linux-gnueabihf-gcc (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
GNU ld (GNU Binutils for Ubuntu) 2.30
BPI-R64>

ray · September 26, 2019, 9:25am

Now retest it with all three

frank-w · September 26, 2019, 10:20am

Compile allready done…will test them if i have a bit time

moore · September 26, 2019, 11:00am

you can modify include/linux/compiler-gcc.h to fix this issue…

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 9896e54..b5fa76d 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -44,9 +44,13 @@
  */
 #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
 !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-# define inline                inline          __attribute__((always_inline))
+/*# define inline              inline          __attribute__((always_inline))
 # define __inline__    __inline__      __attribute__((always_inline))
-# define __inline      __inline        __attribute__((always_inline))
+# define __inline      __inline        __attribute__((always_inline))*/
+/* XXX: check __GNUC_STDC_INLINE__, fix line length */
+# define inline                inline          __attribute__((always_inline)) __attribute__((__gnu_inline__))
+# define __inline__    __inline__      __attribute__((always_inline)) __attribute__((__gnu_inline__))
+# define __inline      __inline        __attribute__((always_inline)) __attribute__((__gnu_inline__))
 #endif

frank-w · September 26, 2019, 1:06pm

Thank you

Which issue will be fixed by your change?

gcc8-issue is already solved by header-file from linux-kernel

Currently i try to fix the warnings

most of them fixed…only 2 less

drivers/mmc/mediatek/mt7622/msdc.c:1603:27: warning: comparison of constant '2' with boolean expression is always true [-Wbool-compare]
         if ( host->app_cmd!=2 ) { //Light 20121225, to prevent recursive call path: msdc_tune_cmdrsp->msdc_app_cmd->msdc_cmd->msdc_tune_cmdrsp
                           ^~
drivers/mmc/mediatek/mt7622/msdc.c: In function 'msdc_dma_transfer':
drivers/mmc/mediatek/mt7622/msdc.c:2087:23: warning: comparison of constant '2' with boolean expression is always true [-Wbool-compare]
     if (host->app_cmd != 2)
                       ^~

i wonder why author of this code compares a boolean with numeric value…

github.com

frank-w/u-boot/blob/bb5684134c743a24d72317fb1bdec7dc8138de83/drivers/mmc/mediatek/mt7622/mmc_core.h#L786


    u32 blklen;       /* block len */
    u32 blkbits;      /* block bits */
    u32 ocr;          /* current ocr */
    u32 ocr_avail;    /* available ocr */    
    u32 timeout_ns;   /* data timeout ns */
    u32 timeout_clks; /* data timeout clks */
    u8  clksrc;       /* clock source */
    u8  hclksrc;       /* clock source */
    u8  id;           /* host id number */
    u8  boot_type;    /* boot type */
	bool app_cmd;
	u32  app_cmd_arg;
	u32  time_read;
    u32   cur_pwr;     /* current power voltage */
    struct mmc_command *cmd;
    void *priv;       /* private data */
    int (*blk_read)(struct mmc_host *host, u8 *dst, u32 src, u32 nblks);
    int (*blk_write)(struct mmc_host *host, u32 dst, u8 *src, u32 nblks);
};


#define MMC_TYPE_UNKNOWN    (0)          /* Unknown card */

so i would suggest change both to

if ( ! host->app_cmd)

will this be right?

i have compiled all 4 versions (sd/emmc,rtl8367/mt7531) with gcc8 for testing:

https://drive.google.com/drive/folders/1Vg3eoHpx3nlZ9pTCZdDpC2l1pJ4rQh5i

please report if there an issues

moore · September 26, 2019, 10:35pm

patch is for this issue to replace disabling weak-option solution.

frank-w:

for gcc7+ we need to fix some compile-errors

common/main.c:31:6: error: 'show_boot_progress' aliased to external symbol '__show_boot_progress'
 void show_boot_progress (int val) __attribute__((weak, alias("__show_boot_progress")));
      ^~~~~~~~~~~~~~~~~~
make[1]: *** [common/main.o] Error 1
make: *** [common] Error 2
make: *** Waiting for unfinished jobs....
arch/arm/lib/board.c:73:6: error: 'coloured_LED_init' aliased to external symbol '__coloured_LED_init'
 void coloured_LED_init(void)
      ^~~~~~~~~~~~~~~~~

frank-w · September 27, 2019, 6:28am

seems to work so far.

1 issue i have is when i load uboot-binary via tftp and try to access ethernet-layer (e.g. run ping). board makes a reset

BPI-R64> setenv ufile u-boot-mtk_r64_sd_rtl8367_gcc8.3.bin
BPI-R64> run tfu
ETH already turn on and power on flow will be skipped...

 Waitting for RX_DMA_BUSY status Start... done

rtk_switch_init ret = 0!!!!!!!!!!!!
Set RTL8367S SGMII 2.5Gbps
 0x1b000014 = 0x00110214
Using mtk_eth device
TFTP from server 192.168.0.10; our IP address is 192.168.0.18
Filename 'u-boot-mtk_r64_sd_rtl8367_gcc8.3.bin'.
Load address: 0x41dffe00
Loading: T T #####################
         28.3 KiB/s
done
Bytes transferred = 295660 (482ec hex)
get filesize 0x482ec
## Starting application at 0x41E00000 ...


U-Boot 2014.04-rc1-00035-g6de72ed2fd-dirty (Sep 27 2019 - 07:48:32)

DRAM:  1008 MiB                                                                 
WARNING: Caches not enabled
...
BPI-R64> ping 192.168.0.10
ETH already turn on and power on flow will be skipped...

 Waitting for RX_DMA_BUSY status Start... done

rtk_switch_init ret = 0!!!!!!!!!!!!
Set RTL8367S SGMII 2.5Gbps
 0x1b000014 = 0x00110214
Using mtk_eth device
data abort
pc : [<7ef5f4ec>]          lr : [<7ef5fe84>]
sp : 7cf29db0  ip : 00000033     fp : 7ef39fa0
r10: 7efd83a0  r9 : 7cf29f40     r8 : 00000001
r7 : 00000000  r6 : 0000002a     r5 : 7ef718d4  r4 : 7efd858e
r3 : 14000045  r2 : 1200a8c0     r1 : 0a00a8c0  r0 : 7efd858e
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
mtk_arch_reset at pre-loader!

this is my definition for loading uboot via tftp (address-calculation is to strip 512b LK-Header from uboot-mtk.bin and stay aligned, so move 512b back from uaddr):

tfu=setexpr umtkaddr ${uaddr} - 0x200;tftp ${umtkaddr} ${ufile};go ${uaddr}
uaddr=0x41E00000

it seems similar to upstream-uboot for mt7623…here network is stalled (no reset) after loading uboot.bin via go-command

maybe anyone have a idea…@ray can i use the register-information to get the crash-location?

arg, wrote the gcc8-image to card and got same problem…seems network is broken here

same code, with gcc5.5 and 6.5 it works (after make clean)

gcc7+8 affected, also if i revert moores change, maybe anybody can check this with the other ethernet-switch

ray · September 27, 2019, 8:15am

sure, PC is your point

but since uboot relocating, you have to adjust that address

addr = 0x7ef5f4ec - relocate_base + 0x41e00000

objdump -x u-boot > u-boot.asm

and find that addr in u-boot.asm

ray · September 27, 2019, 8:17am

btw, second u-boot instance on MT7623 did not crash, but fail to initialize ethernet too.

but when I put it as first it worked just fine

frank-w · September 27, 2019, 10:24am

u-boot.asm (147,5 KB)

BPI-R64> bdinfo 
arch_number = 0x00001DC6
boot_params = 0x40000100
DRAM bank   = 0x00000000
-> start    = 0x40000000
-> size     = 0x3F000000
eth0name    = mtk_eth
ethaddr     = 00:0C:E7:11:22:33
current eth = mtk_eth
ip_addr     = 192.168.0.18
baudrate    = 115200 bps
TLB addr    = 0x7EFF0000
relocaddr   = 0x7EF2C000
reloc off   = 0x3D12C000
irq_sp      = 0x7CF29F40
sp start    = 0x7CF29F30
BPI-R64> version

U-Boot 2014.04-rc1-00035-g6de72ed2fd (Sep 27 2019 - 09:54:06)
arm-linux-gnueabihf-gcc (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
GNU ld (GNU Binutils for Ubuntu) 2.30
BPI-R64> ping 192.168.0.10
ETH already turn on and power on flow will be skipped...

 Waitting for RX_DMA_BUSY status Start... done

rtk_switch_init ret = 0!!!!!!!!!!!!
Set RTL8367S SGMII 2.5Gbps
 0x1b000014 = 0x00110214
Using mtk_eth device
data abort
pc : [<7ef5f6b4>]          lr : [<7ef6003c>]
sp : 7cf29db0  ip : 00000033     fp : 7ef3a01c
r10: 7efd8560  r9 : 7cf29f40     r8 : 00000001
r7 : 00000000  r6 : 0000002a     r5 : 7ef71a84  r4 : 7efd874e
r3 : 14000045  r2 : 1200a8c0     r1 : 0a00a8c0  r0 : 7efd874e
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
mtk_arch_reset at pre-loader!

addr = 7ef5f6b4 (pc) - 0x7EF2C000 (relocaddr) + 0x41e00000 = 41E336B4

41e336a0 l       .text  00000000 $a
41e33720 l       .text  00000000 $d

41e3361c g     F .text  00000084 net_update_ether
41e4dec0 g     O .bss   00000004 protect_2nd_nor

41e336a0 g     F .text  0000008c net_set_ip_header
41e30074 g     F .text  000000c0 simple_strtoul

so i guess crash happens inside net_set_ip_header it’s closest to the crash-address

ray · September 27, 2019, 10:28am

You have to have asm code, which will show exact problem location

frank-w · September 27, 2019, 10:30am

which is the asm-code? i had attached objdump (uboot.asm), but there is only a map of functions

tried this:

$ LANG=C objdump --disassemble-all u-boot > u-boot_complete.asm
objdump: u-boot: .gnu.version_d invalid entry
objdump: u-boot: Bad value

but file contains only “u-boot: file format elf32-little”

ray · September 27, 2019, 10:42am

hehe

try arm toolchain’s objdump

frank-w · September 27, 2019, 10:53am

looks same, content of files similar

$ LANG=C arm-linux-gnueabihf-objdump --disassemble-all u-boot > u-boot_complete.asm
arm-linux-gnueabihf-objdump: u-boot: .gnu.version_d invalid entry
arm-linux-gnueabihf-objdump: u-boot: Bad value
$ LANG=C arm-linux-gnueabihf-objdump -x u-boot > u-boot.asm
arm-linux-gnueabihf-objdump: u-boot: .gnu.version_d invalid entry
$ ls -l $(which arm-linux-gnueabihf-objdump) 
-rwxr-xr-x 1 root root 414128 Mai  8 10:14 /usr/bin/arm-linux-gnueabihf-objdump
$ ls -1 /usr/bin/arm-linux-gnueabihf-*
/usr/bin/arm-linux-gnueabihf-addr2line
/usr/bin/arm-linux-gnueabihf-ar
/usr/bin/arm-linux-gnueabihf-as
/usr/bin/arm-linux-gnueabihf-c++filt
/usr/bin/arm-linux-gnueabihf-cpp
/usr/bin/arm-linux-gnueabihf-cpp-5
/usr/bin/arm-linux-gnueabihf-cpp-6
/usr/bin/arm-linux-gnueabihf-cpp-7
/usr/bin/arm-linux-gnueabihf-cpp-8
/usr/bin/arm-linux-gnueabihf-dwp
/usr/bin/arm-linux-gnueabihf-elfedit
/usr/bin/arm-linux-gnueabihf-gcc
/usr/bin/arm-linux-gnueabihf-gcc-5
/usr/bin/arm-linux-gnueabihf-gcc-6
/usr/bin/arm-linux-gnueabihf-gcc-7
/usr/bin/arm-linux-gnueabihf-gcc-8
/usr/bin/arm-linux-gnueabihf-gcc-ar
/usr/bin/arm-linux-gnueabihf-gcc-ar-5
/usr/bin/arm-linux-gnueabihf-gcc-ar-6
/usr/bin/arm-linux-gnueabihf-gcc-ar-7
/usr/bin/arm-linux-gnueabihf-gcc-ar-8
/usr/bin/arm-linux-gnueabihf-gcc-nm
/usr/bin/arm-linux-gnueabihf-gcc-nm-5
/usr/bin/arm-linux-gnueabihf-gcc-nm-6
/usr/bin/arm-linux-gnueabihf-gcc-nm-7
/usr/bin/arm-linux-gnueabihf-gcc-nm-8
/usr/bin/arm-linux-gnueabihf-gcc-ranlib
/usr/bin/arm-linux-gnueabihf-gcc-ranlib-5
/usr/bin/arm-linux-gnueabihf-gcc-ranlib-6
/usr/bin/arm-linux-gnueabihf-gcc-ranlib-7
/usr/bin/arm-linux-gnueabihf-gcc-ranlib-8
/usr/bin/arm-linux-gnueabihf-gcov
/usr/bin/arm-linux-gnueabihf-gcov-5
/usr/bin/arm-linux-gnueabihf-gcov-6
/usr/bin/arm-linux-gnueabihf-gcov-7
/usr/bin/arm-linux-gnueabihf-gcov-8
/usr/bin/arm-linux-gnueabihf-gcov-dump
/usr/bin/arm-linux-gnueabihf-gcov-dump-5
/usr/bin/arm-linux-gnueabihf-gcov-dump-6
/usr/bin/arm-linux-gnueabihf-gcov-dump-7
/usr/bin/arm-linux-gnueabihf-gcov-dump-8
/usr/bin/arm-linux-gnueabihf-gcov-tool
/usr/bin/arm-linux-gnueabihf-gcov-tool-5
/usr/bin/arm-linux-gnueabihf-gcov-tool-6
/usr/bin/arm-linux-gnueabihf-gcov-tool-7
/usr/bin/arm-linux-gnueabihf-gcov-tool-8
/usr/bin/arm-linux-gnueabihf-gprof
/usr/bin/arm-linux-gnueabihf-ld
/usr/bin/arm-linux-gnueabihf-ld.bfd
/usr/bin/arm-linux-gnueabihf-ld.gold
/usr/bin/arm-linux-gnueabihf-nm
/usr/bin/arm-linux-gnueabihf-objcopy
/usr/bin/arm-linux-gnueabihf-objdump
/usr/bin/arm-linux-gnueabihf-ranlib
/usr/bin/arm-linux-gnueabihf-readelf
/usr/bin/arm-linux-gnueabihf-size
/usr/bin/arm-linux-gnueabihf-strings
/usr/bin/arm-linux-gnueabihf-strip

ray · September 27, 2019, 10:55am

sorry. objdump -d

ray · September 27, 2019, 10:56am

makes everything, even data segments to be decoded as program code

frank-w · September 27, 2019, 10:58am

also a nearly empty output file

$ LANG=C arm-linux-gnueabihf-objdump -d u-boot

u-boot:     file format elf32-littlearm

arm-linux-gnueabihf-objdump: u-boot: .gnu.version_d invalid entry
arm-linux-gnueabihf-objdump: u-boot: Bad value

$ file ./u-boot
./u-boot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /usr/lib, with debug_info, not stripped

this seems to work:

LANG=C arm-linux-gnueabihf-objdump -D -b binary -marm u-boot > u-boot.asm

https://drive.google.com/open?id=13jZuc2ICIkKmclcsI2Jtx1IcppsfYjpd

if i read it right i need to look here:

   336a0:       e3a0201f        mov     r2, #31                                // net_set_ip_header
   336a4:       e3a01c1f        mov     r1, #7936       ; 0x1f00
   336a8:       e3010d92        movw    r0, #7570       ; 0x1d92
   336ac:       ebfff38d        bl      0x304e8
   336b0:       e2504000        subs    r4, r0, #0
   336b4:       1afffb54        bne     0x3240c    //crash here
   336b8:       e1a03008        mov     r3, r8
   336bc:       e3a02000        mov     r2, #0
   336c0:       e3a01004        mov     r1, #4
   336c4:       e3a00001        mov     r0, #1
   336c8:       ebfff443        bl      0x307dc
   336cc:       e2504000        subs    r4, r0, #0
   336d0:       1afffb4d        bne     0x3240c

commands look different to x86 i know but i guess the crash-location is a kind of jump

   3240c:       e1a00004        mov     r0, r4
   32410:       e28ddf92        add     sp, sp, #584    ; 0x248
   32414:       e8bd8df0        pop     {r4, r5, r6, r7, r8, sl, fp, pc}
   32418:       e355000c        cmp     r5, #12
   3241c:       1a00000c        bne     0x32454

ray · September 27, 2019, 11:20am

no, there is something wrong

I had asm with full address, not file offset. Like that

81e00064: e58de000 str lr, [sp]

ray · September 27, 2019, 11:21am

is it same toolchain that build it?

frank-w · September 27, 2019, 11:29am

yes, but for gcc i have multiple files and objdump is only one