$ make CROSS_COMPILE=arm-linux-gnueabihf- mt7622_evb_config
Configuring for mt7622_evb board...
$ make CROSS_COMPILE=arm-linux-gnueabihf-
seems to run, but gpio.h is not found
In file included from common/cmd_gpio.c:12:0:
./arch/arm/include/asm/gpio.h:1:27: fatal error: asm/arch/gpio.h: No such file or directory
#include <asm/arch/gpio.h>
also in original repo i donāt see this fileā¦
$ find -name 'gpio.h' | grep 'asm/arch'
lists only some board-specific files where āarchā is part of folder-name (e.g. arch/arm/include/asm/arch-rmobile/gpio.h).
seems that there was anything broken, after make mrproper it compilesā¦
have now cleaned my r64-branch a bit and it compiles also with mt7531-driver
just make a clone and then
./build.sh config #change switch to mt7531
./build.sh
./build.sh install
currently i try to figure out how to use SD as flash typeā¦emmc compiles fine while SD is broken
/media/data_fast/bpi/uboot/u-boot/include/configs/mt7622_evb.h:412:45: error: 'NFI_BASE' undeclared here (not in a function)
#define CONFIG_SYS_NAND_BASE NFI_BASE
it looks like there is a missing conditionā¦or include order is wrong (board before nand)
imho nand != sd-card or is nand-driver needed for sdcard? tried to add include which defines NFI_base (e.g. asm/arch-mt7622/mt6735.h) but this leads to other errorsā¦any idea about that? @jackzeng@sinovoip@moore
There is no need to enable nand driver if we want to boot from emmc or SD.
you can download native uboot code and type āmake menuconfigā in home directory. choose boot from sd to see what compile options need to be enabled. thanks.
I am not familiar with build.sh build flow. I guess uboot source in bpi github has something different from original one (at least config.in in home directory) . I donāt see such problem if use original uboot source with buildroot-gcc492 toolchain (type make menuconfig; make to build uboot image) and uboot partition in below image was also built by this way.
Most users donāt have buildroot-toolchain. Can you please try with ubuntuās linaro toolchain (gcc6 arm-linux-gnueabihf)?
i have removed buildroot-toolchain from makefile and only call make with linaro-toolchain in my build.sh (also menuconfig) so itās easier to read.
i tried official repo with 4.4 and 4.19, changed flash-type to SD with make menuconfig before and compiled with build.sh and āmake CROSS_COMPILE=arm-linux-gnueabihf-ā
all ended up with same error
/media/data_fast/bpi/kernel/BPI-R64-BSP-4.19_official/u-boot-mt/include/configs/mt7622_evb.h:412:45: error: āNFI_BASEā undeclared here (not in a function)
#define CONFIG_SYS_NAND_BASE NFI_BASE
^
drivers/mtd/nand/nand.c:29:37: note: in expansion of macro āCONFIG_SYS_NAND_BASEā
#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE }
^~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/nand.c:52:57: note: in expansion of macro āCONFIG_SYS_NAND_BASE_LISTā
static ulong base_address[CONFIG_SYS_MAX_NAND_DEVICE] = CONFIG_SYS_NAND_BASE_LIST;
^~~~~~~~~~~~~~~~~~~~~~~~~
which Value should CONFIG_SYS_NAND_BASE/NFI_BASE have for SD-card? i have found 2 diferent definitions for mt7622
i wonder why different toolchain does not show this errorā¦maybe nand-include is missing for SD? these includes are not used or after the mt7622.h
as far as i see the only include of mt7622_evb.h is in ./arch/arm/lib/bootm.c and here is no include to the nand (i guess itās later in storage-commands)ā¦isnāt it better to define IO_PHYS / NFI_BASE in board-header (to use it there) or some āglobalā header-file instead of the NAND-driver?
i wonder why it happens because the call to this value comes from the universal-nand-driverā¦shouldnāt it not include the nand-headers first? havnāt found out the order yet
if i add the 2 defines to the board-header, i donāt get the expected duplicate definitionā¦instead i got an undefined reference for board_nand_init in drivers/mtd/nand/nand.c:180
both are included if CONFIG_MTK_MTD_NAND is setā¦this is only set if ON_BOARD_*NAND_FLASH_COMPONENT is selectedā¦not if flashtype set to SD (OFF_BOARD_SD_CARD_COMPONENT)
so i wonder why drivers/mtd/nand/nand.c is used
iāve seen that for flashtype=SD nand and mtd are activated including the CMD_*-options. disabled them and now iām able to compileā¦strange that you can build without this change
BPI do have original/up-to-date uboot source code, but they missed some changes in above github. I guess they just extracted related patch/files from up-to-date uboot to current uboot codebase. Iāll suggest they can put original code to github as reference, thanks.
ok,as i expected you use another repoā¦is this public? This github-repo (v2014-04) was my only source. Or are you talking about upstream-code (actual uboot v2019-xx)?
btw. my uboot does not boot ;( compiled with gcc6 and 5.5, maybe same problem as with older r2-ubootā¦which does also not boot with gcc5.5+
Is your inlining-patch for this issue? edit: tried it, but same result (gcc6.5 with inline-patch)
have now compiled with gcc 4.8 (ubuntu 14.4) and here it boots, only strange message:
DRAM: 112 MiB
WARNING: Caches not enabled
dev_num = 1
***size=4096, offset=1310720, blk_start=2560, blk_cnt=8
*** Error - default environment is too large
In: serial
Out: serial
Err: serial
dev_num = 1
***size=4096, offset=1310720, blk_start=2560, blk_cnt=8
*** Error - default environment is too large
Net: mtk_eth
Uip activated
Hit any key to stop autoboot: 0
Unknown command 'No' - try 'help'
BPI-R64>
BPI-R64>
BPI-R64> printenv
Environment size: 1/4092 bytes
BPI-R64>
ok, fixed by setting CONFIG_ENV_SIZE to 8K
network works with rtl8367-switch, load from my menu currently not (because service is set to linux-4.19 instead of linux), ls works on the partition 1:1 (=sd)
btw. does anybody know memory-location of uboot? i want to add tftp-option for loading uboot, but did not find uboots memory-position (before relocation)
[PART] load "tee1" from 0x0000000000080200 (dev) to 0x43000DC0 (mem) [SUCCESS]
[PART] load speed: 2752KB/s, 62032 bytes, 22ms
load tee1 (ret=0)
[BLDR] bldr load tee part ret=0x0, addr=0x43001000
[get_part] part->nr_sects=768, part->info->name=preloader
[get_part] part->nr_sects=512, part->info->name=tee1
[get_part] part->nr_sects=1024, part->info->name=lk
[BLDR] boot part. not found
[BLDR] part_load_images ret=0x0
[BLDR] Others, jump to ATF
[BLDR] jump to 0x41E00000
[BLDR] <0x41E00000>=0xEA00000F
[BLDR] <0x41E00004>=0xE59FF014
U-Boot 2014.04-rc1-00018-g7a9081b-dirty (Sep 21 2019 - 20:15:23)
maybe 0x41E00004 is ubootās address, but on r2 this is printed more cleanly
just a small update on gcc-issue (does not boot if compiled with linaro gcc 5.5+)
if i enable debug in mt7622_evb.h i see this:
U-Boot code: FFFFFFFF -> FFFFFFFF BSS: -> FFFFFFFF
monitor len: 00000000
ramsize: 3F000000
TLB table from 7eff0000 to 7eff4000
Top of RAM usable for U-Boot at: 7eff0000
Reserving 0k for U-Boot at: 7eff0000 <<<<<<<<<<<<<<< 0k is a little bit, right? :)
Reserving 32772k for malloc() at: 7cfef000
Reserving 32 Bytes for Board Info at: 7cfeefe0
Reserving 160 Bytes for Global Data at: 7cfeef40
New Stack Pointer is: 7cfeef30
RAM Configuration:
Bank #0: 40000000 1008 MiB
relocation Offset is: 7eff0001 <<<<<<<<<<<<<< not aligned, last 1 is strange
basicly it hangs after the dram-information, not showing uboot-version (like it does if compiled with gcc4.8)
with the great help of @ray we have fixed the gcc5.5Ā±issue (compile but not boot) by removing object-copy filtering:
so uboot is now compilable with ubuntu 18.4 (gcc6.5) and boots up correctly
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)
^~~~~~~~~~~~~~~~~
arch/arm/lib/board.c:90:6: error: 'blue_led_off' aliased to external symbol '__blue_led_off'
void blue_led_off(void) __attribute__((weak, alias("__blue_led_off")));
^~~~~~~~~~~~
arch/arm/lib/board.c:88:6: error: 'blue_led_on' aliased to external symbol '__blue_led_on'
void blue_led_on(void) __attribute__((weak, alias("__blue_led_on")));
^~~~~~~~~~~
arch/arm/lib/board.c:86:6: error: 'yellow_led_off' aliased to external symbol '__yellow_led_off'
void yellow_led_off(void) __attribute__((weak, alias("__yellow_led_off")));
^~~~~~~~~~~~~~
arch/arm/lib/board.c:84:6: error: 'yellow_led_on' aliased to external symbol '__yellow_led_on'
void yellow_led_on(void) __attribute__((weak, alias("__yellow_led_on")));
^~~~~~~~~~~~~
arch/arm/lib/board.c:82:6: error: 'green_led_off' aliased to external symbol '__green_led_off'
void green_led_off(void) __attribute__((weak, alias("__green_led_off")));
^~~~~~~~~~~~~
arch/arm/lib/board.c:80:6: error: 'green_led_on' aliased to external symbol '__green_led_on'
void green_led_on(void) __attribute__((weak, alias("__green_led_on")));
^~~~~~~~~~~~
arch/arm/lib/board.c:78:6: error: 'red_led_off' aliased to external symbol '__red_led_off'
void red_led_off(void) __attribute__((weak, alias("__red_led_off")));
^~~~~~~~~~~
arch/arm/lib/board.c:76:6: error: 'red_led_on' aliased to external symbol '__red_led_on'
void red_led_on(void) __attribute__((weak, alias("__red_led_on")));
^~~~~~~~~~
i tried to fix them like here by disabling the weak-option (not the best way,right? maybe weak is needed to overwrite these functionsā¦)
but now i get these:
LD lib/built-in.o
lib/time.o: In function `__raw_writesb':
/media/data_fast/bpi/uboot/u-boot/arch/arm/include/asm/io.h:80: multiple definition of `__raw_writesb'
lib/display_options.o:/media/data_fast/bpi/uboot/u-boot/arch/arm/include/asm/io.h:80: first defined here
lib/time.o: In function `__raw_writesw':
/media/data_fast/bpi/uboot/u-boot/arch/arm/include/asm/io.h:88: multiple definition of `__raw_writesw'
...
