[v3,00/20] Refactor the architecture parts of mt7628

Thanks Daniel.

On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> Hi Mauro,
>
> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>> FYI
>> I've been using this patchset for over a week without any adverse effect.
>> It allowed me to port to VoCore2 board.
>> Should I add a "Tested-by" flag?
>> If so: how should I do it?
>>
>> Regards
>> Mauro Codarelli
>>
> sorry that I could respond to your questions earlier. I've pushed the
> complete patch set from Weijie to:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
I tried to use this repo/branch, but something is wrong (or I goofed badly).
> Maybe this helps you with development. If you have a bootable patch set
> (you can do MMC later) for your VoCore2 board, please submit a regular
> patch series based on that branch so that we can review again.
I *do* have a bootable patchset built on top of master + Nemirovsky
"reconfigurable cpu clocks" + Weijie v3.
Result is fully working, including net and mmc/SD.

This patchset applies cleanly to uboot-mips/testing and compile
apparently without errors, but resulting u-boot.bin does not work.
By "does not work" I mean it does not utter a single char on debug
serial.

I tried to do a complete diff between my working tree and this
non-working one and there are tons of differences, but I couldn't
spot anything that might be relevant.

I am unsure on how to proceed; please advise.
> ===8<----
Many thanks
Mauro Condarelli


My complete patchset follows:
This includes some project-specific settings I need to remove
before actual submission, but I left them in because *this*
is working for me.
0:1 uboot.scr && source 84000000 && echo Flash updated\0"               
                                    \
+    "boot_a=echo \"Loading System A\";load mmc 0:5 85000000
/boot/uImage; setenv bootargs \"${default_bootargs} mtdparts=${mtdparts}
root=/dev/mmcblk0p5\"; bootm ${fileaddr}\0"                            \
+    "boot_b=echo \"Loading System B\";load mmc 0:6 85000000
/boot/uImage; setenv bootargs \"${default_bootargs} mtdparts=${mtdparts}
root=/dev/mmcblk0p6\"; bootm ${fileaddr}\0"                            \
+    "boot_r=echo \"Loading Recovery\"; setenv bootargs
\"${default_bootargs} mtdparts=${mtdparts} root=/dev/mtdblock5\"; bootm
bc050000\0"                                                \
+    "remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT;
saveenv; elif env exixts BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv;
elif env exists BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi\0"   
        \
+    "boot_now=if test \"${BOOT_CURRENT}\" = A; then run boot_a; elif
test \"${BOOT_CURRENT}\" = B; then run boot_b; elif env exists
BOOT_A_GOOD; then run boot_a; elif env exists test BOOT_B_GOOD; then run
boot_b; else run boot_r; fi\0"    \
+    "do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now"
+    // "\0bootcmd=mmc rescan && run do_boot"
+
+#endif //__VOCORE2_CONFIG_H__

Hi Mauro,

On 11.02.20 11:58, Mauro Condarelli wrote:
> Thanks Daniel.
> 
> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
>> Hi Mauro,
>>
>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>>> FYI
>>> I've been using this patchset for over a week without any adverse effect.
>>> It allowed me to port to VoCore2 board.
>>> Should I add a "Tested-by" flag?
>>> If so: how should I do it?
>>>
>>> Regards
>>> Mauro Codarelli
>>>
>> sorry that I could respond to your questions earlier. I've pushed the
>> complete patch set from Weijie to:
>>
>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
> I tried to use this repo/branch, but something is wrong (or I goofed badly).

Just a quick reply: I tested u-boot-mips/testing today and it works just
fine on both LinkIt and the GARDENA board. So there is nothing wrong
with this repository AFAICT.

You might need to rebase your patch on top of this branch, as some files
might have changes in the meantime.

Thanks,
Stefan

>> Maybe this helps you with development. If you have a bootable patch set
>> (you can do MMC later) for your VoCore2 board, please submit a regular
>> patch series based on that branch so that we can review again.
> I *do* have a bootable patchset built on top of master + Nemirovsky
> "reconfigurable cpu clocks" + Weijie v3.
> Result is fully working, including net and mmc/SD.
> 
> This patchset applies cleanly to uboot-mips/testing and compile
> apparently without errors, but resulting u-boot.bin does not work.
> By "does not work" I mean it does not utter a single char on debug
> serial.
> 
> I tried to do a complete diff between my working tree and this
> non-working one and there are tons of differences, but I couldn't
> spot anything that might be relevant.
> 
> I am unsure on how to proceed; please advise.
>> ===8<----
> Many thanks
> Mauro Condarelli
> 
> 
> My complete patchset follows:
> This includes some project-specific settings I need to remove
> before actual submission, but I left them in because *this*
> is working for me.
> ==========================================
>  From f1828bcacbd3fc3bc8aa9243b302ab2b7a509d88 Mon Sep 17 00:00:00 2001
> From: Mauro Condarelli <mc5686 at mclink.it>
> Date: Tue, 17 Dec 2019 10:54:21 +0100
> Subject: [PATCH] Add support for SoM "VoCore2".
> 
> Small patch series to add support for VoCore/VoCore2 board.
> 
> VoCore is open hardware and runs OpenWrt/LEDE.
> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
> It will help you to make a smart house, study embedded system
> or even make the tiniest router in the world.
> 
> Details about this SoM can be found at "https://vocore.io/v2.html".
> 
> Series-notes:
> This port is working for me and able to boot Linux v5.0.
> Standard subsystems are enabled (SPI NOR, MMC/SD and USB).
> Network is not currently enabled as my Vocore2 board networking
> relies essentially on WiFi (which works under Linux).
> END
> 
> Series-to: uboot
> Series-name: VoCore2
> Series-cc: danielschwierzeck
> Series-cc: stroese
> Series-cc: Weijie Gao <weijie.gao at mediatek.com>
> Series-version: 5
> 
> Series-changes: 2
> - Removed some dead code
> - Changed Author to my full name (no nick)
> - Removed unwanted fixup to .dts generation (not my call).
> - Fixed commit message
> - Fixed various variables/filenames to include Vendor name
> - Changed Vendor name (Vonger -> Vocore)
> 
> Series-changes: 3
> - based on top of Weijie Gao patchset:
>      "[v3,xx/20]Refactor the architecture parts of mt7628"
> 
> Series-changes: 4
> - Reverted some overzealous DTS cleaning.
> - Added support for bootcount
> 
> Series-changes: 5
> - Added network setup.
> - Move back environment to SPI NOR.
> - Changes to environment default settings.
> 
> Signed-off-by: Mauro Condarelli <mc5686 at mclink.it>
> ---
>   arch/mips/dts/Makefile               |   1 +
>   arch/mips/dts/mt7628a.dtsi           |   5 ++
>   arch/mips/dts/vocore_vocore2.dts     |  78 ++++++++++++++++++++
>   arch/mips/mach-mtmips/Kconfig        |   8 ++
>   board/vocore/vocore2/Kconfig         |  12 +++
>   board/vocore/vocore2/Makefile        |   3 +
>   board/vocore/vocore2/board.c         |  33 +++++++++
>   configs/vocore2_defconfig            | 105 +++++++++++++++++++++++++++
>   configs/vocore2_defconfig_ENV_IN_FAT | 104 ++++++++++++++++++++++++++
>   include/configs/vocore2.h            |  76 +++++++++++++++++++
>   10 files changed, 425 insertions(+)
>   create mode 100644 arch/mips/dts/vocore_vocore2.dts
>   create mode 100644 board/vocore/vocore2/Kconfig
>   create mode 100644 board/vocore/vocore2/Makefile
>   create mode 100644 board/vocore/vocore2/board.c
>   create mode 100644 configs/vocore2_defconfig
>   create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
>   create mode 100644 include/configs/vocore2.h
> 
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index cbd0c8bc8b..f711e9fb59 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +=
> netgear,dgnd3700v2.dtb
>   dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f at st1704.dtb
>   dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>   dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>   dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>   dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>   dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> index 6baa63add3..192599c37f 100644
> --- a/arch/mips/dts/mt7628a.dtsi
> +++ b/arch/mips/dts/mt7628a.dtsi
> @@ -402,6 +402,11 @@
>           builtin-cd = <1>;
>           r_smpl = <1>;
>   
> +        bus-width = <4>;
> +        max-frequency = <48000000>;
> +        cap-sd-highspeed;
> +        cap-mmc-highspeed;
> +
>           clocks = <&clk48m>, <&clkctrl CLK_SDXC>;
>           clock-names = "source", "hclk";
>   
> diff --git a/arch/mips/dts/vocore_vocore2.dts
> b/arch/mips/dts/vocore_vocore2.dts
> new file mode 100644
> index 0000000000..1d611abb73
> --- /dev/null
> +++ b/arch/mips/dts/vocore_vocore2.dts
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Mauro Condarelli <mc5686 at mclink.it>
> + */
> +
> +/dts-v1/;
> +
> +#include "mt7628a.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +    compatible = "vocore,vocore2", "ralink,mt7628a-soc";
> +    model = "VoCore2";
> +
> +    aliases {
> +        serial0 = &uart2;
> +        spi0 = &spi0;
> +    };
> +
> +    memory at 0 {
> +        device_type = "memory";
> +        reg = <0x0 0x08000000>;
> +    };
> +    leds {
> +        compatible = "gpio-leds";
> +
> +        power {
> +            label = "vocore:power";
> +            gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
> +            default-state = "off";
> +        };
> +    };
> +
> +    chosen {
> +        bootargs = "console=ttyS2,115200";
> +        stdout-path = &uart2;
> +    };
> +};
> +
> +&pinctrl {
> +    state_default: pin_state {
> +        p0led {
> +            groups = "p0led_a";
> +            function = "led";
> +        };
> +    };
> +};
> +
> +&uart2 {
> +    status = "okay";
> +};
> +
> +&spi0 {
> +    status = "okay";
> +    nor0: spi-flash at 0 {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        compatible = "jedec,spi-nor";
> +        spi-max-frequency = <25000000>;
> +        reg = <0>;
> +    };
> +};
> +
> +&eth {
> +    status = "okay";
> +
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&ephy_iot_mode>;
> +    mediatek,poll-link-phy = <0>;
> +};
> +
> +&mmc {
> +    status = "okay";
> +
> +    pinctrl-names = "default";
> +    pinctrl-0 = <&sd_iot_mode>;
> +    pinctrl-1 = <&sd_iot_mode>;
> +};
> diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
> index bcd635f438..489e466daf 100644
> --- a/arch/mips/mach-mtmips/Kconfig
> +++ b/arch/mips/mach-mtmips/Kconfig
> @@ -83,6 +83,13 @@ config BOARD_MT7628_RFB
>         SPI-NOR flash, 1 built-in switch with 5 ports, 1 UART, 1 USB host,
>         1 SDXC, 1 PCIe socket and JTAG pins.
>   
> +config BOARD_VOCORE2
> +    bool "VoCore2"
> +    depends on SOC_MT7628
> +    help
> +      VoCore VoCore2 board has a MT7628 SoC with 128 MiB of RAM
> +      and 16 MiB of flash (SPI).
> +
>   endchoice
>   
>   config SPL_UART2_SPIS_PINMUX
> @@ -96,5 +103,6 @@ config SPL_UART2_SPIS_PINMUX
>   source "board/gardena/smart-gateway-mt7688/Kconfig"
>   source "board/mediatek/mt7628/Kconfig"
>   source "board/seeed/linkit-smart-7688/Kconfig"
> +source "board/vocore/vocore2/Kconfig"
>   
>   endmenu
> diff --git a/board/vocore/vocore2/Kconfig b/board/vocore/vocore2/Kconfig
> new file mode 100644
> index 0000000000..baeff31b69
> --- /dev/null
> +++ b/board/vocore/vocore2/Kconfig
> @@ -0,0 +1,12 @@
> +if BOARD_VOCORE2
> +
> +config SYS_BOARD
> +    default "vocore2"
> +
> +config SYS_VENDOR
> +    default "vocore"
> +
> +config SYS_CONFIG_NAME
> +    default "vocore2"
> +
> +endif
> diff --git a/board/vocore/vocore2/Makefile b/board/vocore/vocore2/Makefile
> new file mode 100644
> index 0000000000..70cd7a8e56
> --- /dev/null
> +++ b/board/vocore/vocore2/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-y += board.o
> diff --git a/board/vocore/vocore2/board.c b/board/vocore/vocore2/board.c
> new file mode 100644
> index 0000000000..d387715d14
> --- /dev/null
> +++ b/board/vocore/vocore2/board.c
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Mauro Condarelli <mc5686 at mclink.it>
> + *
> + * Note: this is largely copied from:
> + *       board/seeed/linkit_smart_7688/board.c
> + *       Copyright (C) 2018 Stefan Roese <sr at denx.de>
> + */
> +
> +#include <common.h>
> +#include <asm/io.h>
> +
> +#define MT76XX_GPIO1_MODE   0x10000060
> +
> +void board_debug_uart_init(void)
> +{
> +    void __iomem *gpio_mode;
> +
> +    /* Select UART2 mode instead of GPIO mode (default) */
> +    gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100);
> +    clrbits_le32(gpio_mode, GENMASK(27, 26));
> +}
> +
> +int board_early_init_f(void)
> +{
> +    /*
> +     * The pin muxing of UART2 also needs to be done, if debug uart
> +     * is not enabled. So we need to call this function here as well.
> +     */
> +    board_debug_uart_init();
> +
> +    return 0;
> +}
> diff --git a/configs/vocore2_defconfig b/configs/vocore2_defconfig
> new file mode 100644
> index 0000000000..d243c0f79b
> --- /dev/null
> +++ b/configs/vocore2_defconfig
> @@ -0,0 +1,105 @@
> +CONFIG_MIPS=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_ENV_SIZE=0x1000
> +CONFIG_ENV_SECT_SIZE=0x1000
> +CONFIG_ENV_OFFSET=0x04e000
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x20000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL=y
> +CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
> +CONFIG_SYS_BOOTCOUNT_ADDR=0xb000006c
> +CONFIG_ARCH_MTMIPS=y
> +CONFIG_BOARD_VOCORE2=y
> +CONFIG_SPL_UART2_SPIS_PINMUX=y
> +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
> +CONFIG_MIPS_BOOT_FDT=y
> +CONFIG_ENV_VARS_UBOOT_CONFIG=y
> +CONFIG_SYS_BOOT_GET_CMDLINE=y
> +CONFIG_SYS_BOOT_GET_KBD=y
> +CONFIG_FIT=y
> +CONFIG_FIT_SIGNATURE=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> +CONFIG_OF_STDOUT_VIA_ALIAS=y
> +CONFIG_USE_BOOTARGS=y
> +CONFIG_LOGLEVEL=8
> +CONFIG_SYS_CONSOLE_INFO_QUIET=y
> +CONFIG_VERSION_VARIABLE=y
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_BOARD_EARLY_INIT_F=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +CONFIG_SPL_NOR_SUPPORT=y
> +CONFIG_HUSH_PARSER=y
> +CONFIG_CMD_LICENSE=y
> +# CONFIG_BOOTM_NETBSD is not set
> +# CONFIG_BOOTM_PLAN9 is not set
> +# CONFIG_BOOTM_RTEMS is not set
> +# CONFIG_BOOTM_VXWORKS is not set
> +# CONFIG_CMD_ELF is not set
> +# CONFIG_CMD_XIMG is not set
> +# CONFIG_CMD_CRC32 is not set
> +CONFIG_CMD_MEMINFO=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_GPT_RENAME=y
> +# CONFIG_CMD_LOADS is not set
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_MTD=y
> +CONFIG_CMD_PART=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_USB=y
> +CONFIG_CMD_WDT=y
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_MII=y
> +CONFIG_CMD_PING=y
> +CONFIG_CMD_BOOTCOUNT=y
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_FAT=y
> +CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
> +CONFIG_MTDPARTS_DEFAULT="spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)"
> +CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
> +CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_SPL_DM=y
> +# CONFIG_DM_DEVICE_REMOVE is not set
> +CONFIG_BOOTCOUNT_LIMIT=y
> +CONFIG_LED=y
> +CONFIG_LED_BLINK=y
> +CONFIG_LED_GPIO=y
> +CONFIG_MMC=y
> +CONFIG_DM_MMC=y
> +# CONFIG_MMC_HW_PARTITIONING is not set
> +CONFIG_MMC_MTK=y
> +CONFIG_MTD=y
> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_SPI_FLASH_MTD=y
> +CONFIG_MT7628_ETH=y
> +CONFIG_PHY=y
> +CONFIG_MT76X8_USB_PHY=y
> +# CONFIG_RAM_ROCKCHIP_DEBUG is not set
> +CONFIG_SPECIFY_CONSOLE_INDEX=y
> +CONFIG_CONS_INDEX=3
> +CONFIG_SPI=y
> +CONFIG_MT7621_SPI=y
> +CONFIG_USB=y
> +CONFIG_DM_USB=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_WDT=y
> +CONFIG_WDT_MT7621=y
> +CONFIG_FS_EXT4=y
> +CONFIG_FAT_WRITE=y
> +CONFIG_LZMA=y
> +CONFIG_LZO=y
> diff --git a/configs/vocore2_defconfig_ENV_IN_FAT
> b/configs/vocore2_defconfig_ENV_IN_FAT
> new file mode 100644
> index 0000000000..02727859e4
> --- /dev/null
> +++ b/configs/vocore2_defconfig_ENV_IN_FAT
> @@ -0,0 +1,104 @@
> +CONFIG_MIPS=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_ENV_SIZE=0x1000
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x20000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL=y
> +CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
> +CONFIG_SYS_BOOTCOUNT_ADDR=0xb000006c
> +CONFIG_ARCH_MTMIPS=y
> +CONFIG_BOARD_VOCORE2=y
> +CONFIG_SPL_UART2_SPIS_PINMUX=y
> +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
> +CONFIG_MIPS_BOOT_FDT=y
> +CONFIG_ENV_VARS_UBOOT_CONFIG=y
> +CONFIG_SYS_BOOT_GET_CMDLINE=y
> +CONFIG_SYS_BOOT_GET_KBD=y
> +CONFIG_FIT=y
> +CONFIG_FIT_SIGNATURE=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> +CONFIG_OF_STDOUT_VIA_ALIAS=y
> +CONFIG_USE_BOOTARGS=y
> +CONFIG_LOGLEVEL=8
> +CONFIG_SYS_CONSOLE_INFO_QUIET=y
> +CONFIG_VERSION_VARIABLE=y
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_BOARD_EARLY_INIT_F=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +CONFIG_SPL_NOR_SUPPORT=y
> +CONFIG_HUSH_PARSER=y
> +CONFIG_CMD_LICENSE=y
> +# CONFIG_BOOTM_NETBSD is not set
> +# CONFIG_BOOTM_PLAN9 is not set
> +# CONFIG_BOOTM_RTEMS is not set
> +# CONFIG_BOOTM_VXWORKS is not set
> +# CONFIG_CMD_ELF is not set
> +# CONFIG_CMD_XIMG is not set
> +# CONFIG_CMD_CRC32 is not set
> +CONFIG_CMD_MEMINFO=y
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_GPT_RENAME=y
> +# CONFIG_CMD_LOADS is not set
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_MTD=y
> +CONFIG_CMD_PART=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_USB=y
> +CONFIG_CMD_WDT=y
> +CONFIG_CMD_DHCP=y
> +CONFIG_CMD_MII=y
> +CONFIG_CMD_PING=y
> +CONFIG_CMD_BOOTCOUNT=y
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_FAT=y
> +CONFIG_CMD_FS_GENERIC=y
> +CONFIG_CMD_MTDPARTS=y
> +CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
> +CONFIG_MTDPARTS_DEFAULT="spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)"
> +CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
> +CONFIG_ENV_IS_IN_FAT=y
> +CONFIG_ENV_FAT_INTERFACE="mmc"
> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_SPL_DM=y
> +# CONFIG_DM_DEVICE_REMOVE is not set
> +CONFIG_BOOTCOUNT_LIMIT=y
> +CONFIG_LED=y
> +CONFIG_LED_BLINK=y
> +CONFIG_LED_GPIO=y
> +CONFIG_MMC=y
> +CONFIG_DM_MMC=y
> +# CONFIG_MMC_HW_PARTITIONING is not set
> +CONFIG_MMC_MTK=y
> +CONFIG_MTD=y
> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_SPI_FLASH_MTD=y
> +CONFIG_MT7628_ETH=y
> +CONFIG_PHY=y
> +CONFIG_MT76X8_USB_PHY=y
> +# CONFIG_RAM_ROCKCHIP_DEBUG is not set
> +CONFIG_SPECIFY_CONSOLE_INDEX=y
> +CONFIG_CONS_INDEX=3
> +CONFIG_SPI=y
> +CONFIG_MT7621_SPI=y
> +CONFIG_USB=y
> +CONFIG_DM_USB=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_WDT=y
> +CONFIG_WDT_MT7621=y
> +CONFIG_FS_EXT4=y
> +CONFIG_LZMA=y
> +CONFIG_LZO=y
> diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h
> new file mode 100644
> index 0000000000..0e8f063acf
> --- /dev/null
> +++ b/include/configs/vocore2.h
> @@ -0,0 +1,76 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2019 Mauro Condarelli <mc5686 at mclink.it>
> + */
> +
> +#ifndef __VOCORE2_CONFIG_H__
> +#define __VOCORE2_CONFIG_H__
> +
> +/* CPU */
> +#define CONFIG_SYS_MIPS_TIMER_FREQ    290000000
> +
> +/* RAM */
> +#define CONFIG_SYS_SDRAM_BASE        0x80000000
> +
> +#define CONFIG_SYS_LOAD_ADDR    CONFIG_SYS_SDRAM_BASE + 0x100000
> +
> +#define CONFIG_SYS_INIT_SP_OFFSET    0x400000
> +
> +/* SPL */
> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
> +#define CONFIG_SKIP_LOWLEVEL_INIT
> +#endif
> +
> +#define CONFIG_SYS_UBOOT_START        CONFIG_SYS_TEXT_BASE
> +#define CONFIG_SPL_BSS_START_ADDR    0x80010000
> +#define CONFIG_SPL_BSS_MAX_SIZE        0x10000
> +#define CONFIG_SPL_MAX_SIZE        0x10000
> +
> +/* Dummy value */
> +#define CONFIG_SYS_UBOOT_BASE        0
> +
> +/* Serial SPL */
> +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SERIAL_SUPPORT)
> +#define CONFIG_SYS_NS16550_MEM32
> +#define CONFIG_SYS_NS16550_CLK        40000000
> +#define CONFIG_SYS_NS16550_REG_SIZE    -4
> +#define CONFIG_SYS_NS16550_COM3        0xb0000e00
> +#define CONFIG_CONS_INDEX        3
> +
> +#endif
> +
> +/* UART */
> +#define CONFIG_SYS_BAUDRATE_TABLE    { 9600, 19200, 38400, 57600, 115200, \
> +                    230400, 460800, 921600 }
> +
> +/* RAM */
> +#define CONFIG_SYS_MEMTEST_START    0x80100000
> +#define CONFIG_SYS_MEMTEST_END        0x80400000
> +
> +/* Memory usage */
> +#define CONFIG_SYS_MAXARGS        64
> +#define CONFIG_SYS_MALLOC_LEN        (1024 * 1024)
> +#define CONFIG_SYS_BOOTPARAMS_LEN    (128 * 1024)
> +#define CONFIG_SYS_CBSIZE        512
> +
> +/* U-Boot */
> +#define CONFIG_SYS_MONITOR_BASE        CONFIG_SYS_TEXT_BASE
> +
> +/* Environment settings */
> +#define CONFIG_BOOTCOMMAND \
> +    "run fupdate; setenv bootargs ${default_bootargs}
> mtdparts=${mtdparts} root=/dev/mtdblock5 && bootm 1c050000"
> +//  "load mmc 0:1 85000000 recov.uImage && load mmc 0:1 86000000
> recov.squashfs && setenv bootargs ${default_bootargs}
> mtdparts=${mtdparts} rd_start=0x${fileaddr} rd_size=0x${filesize} &&
> bootm 85000000;"
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> +    "default_bootargs=earlyprintk rootwait console=ttyS2,115200\0"
>                                                                         
>          \
> +    "mtdids=nor0=spi0.0\0"
>                                                              \
> +
> "mtdparts=spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)\0"
>                                                                          \
> +    "fupdate=mmc rescan && load mmc 0:1 84000000 uboot.scr && fatrm mmc
> 0:1 uboot.scr && source 84000000 && echo Flash updated\0"
>                                      \
> +    "boot_a=echo \"Loading System A\";load mmc 0:5 85000000
> /boot/uImage; setenv bootargs \"${default_bootargs} mtdparts=${mtdparts}
> root=/dev/mmcblk0p5\"; bootm ${fileaddr}\0"                            \
> +    "boot_b=echo \"Loading System B\";load mmc 0:6 85000000
> /boot/uImage; setenv bootargs \"${default_bootargs} mtdparts=${mtdparts}
> root=/dev/mmcblk0p6\"; bootm ${fileaddr}\0"                            \
> +    "boot_r=echo \"Loading Recovery\"; setenv bootargs
> \"${default_bootargs} mtdparts=${mtdparts} root=/dev/mtdblock5\"; bootm
> bc050000\0"                                                \
> +    "remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT;
> saveenv; elif env exixts BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv;
> elif env exists BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi\0"
>          \
> +    "boot_now=if test \"${BOOT_CURRENT}\" = A; then run boot_a; elif
> test \"${BOOT_CURRENT}\" = B; then run boot_b; elif env exists
> BOOT_A_GOOD; then run boot_a; elif env exists test BOOT_B_GOOD; then run
> boot_b; else run boot_r; fi\0"    \
> +    "do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now"
> +    // "\0bootcmd=mmc rescan && run do_boot"
> +
> +#endif //__VOCORE2_CONFIG_H__
> 


Viele Grüße,
Stefan Roese

Thanks for the fast answer, Stefan.

On 2/11/20 12:16 PM, Stefan wrote:
> Hi Mauro,
> ===8<----
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed
>> badly).
>
> Just a quick reply: I tested u-boot-mips/testing today and it works just
> fine on both LinkIt and the GARDENA board. So there is nothing wrong
> with this repository AFAICT.
Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
(that's where our boards are different), but I couldn't spot any relevant
difference.

> You might need to rebase your patch on top of this branch, as some files
> might have changes in the meantime.
What is the recommended procedure, in this case?
I did a:
  git format-patch --full-index -o ../transport weijie.v3
on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
of course), an then I tried simply (on u-boot-mips):
  git checkout -b vocore2 testing
  git am -3 ../transport/*

>
> Thanks,
> Stefan
> ===8<----
Regards
Mauro

On 11.02.20 13:34, Mauro Condarelli wrote:
> Thanks for the fast answer, Stefan.
> 
> On 2/11/20 12:16 PM, Stefan wrote:
>> Hi Mauro,
>> ===8<----
>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>>> I tried to use this repo/branch, but something is wrong (or I goofed
>>> badly).
>>
>> Just a quick reply: I tested u-boot-mips/testing today and it works just
>> fine on both LinkIt and the GARDENA board. So there is nothing wrong
>> with this repository AFAICT.
> Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
> (that's where our boards are different), but I couldn't spot any relevant
> difference.

Correct, I have not selected this one. You need to select it via "make
menuconfig" for your board and save it to your defconfig by "make
savedefconfig".

If this does not work, then please double-check, if the correct code is
called in this pinx-mux case.

>> You might need to rebase your patch on top of this branch, as some files
>> might have changes in the meantime.
> What is the recommended procedure, in this case?
> I did a:
>    git format-patch --full-index -o ../transport weijie.v3
> on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
> of course), an then I tried simply (on u-boot-mips):
>    git checkout -b vocore2 testing
>    git am -3 ../transport/*

This sounds like a valid approach.

There are many ways. I usually use "git rebase" for this:

In your case:

- Check out your current working branch
- git checkout -b new-version
- git rebase u-boot-mips/testing

The rebase command will most likely issue some warnings or errors on
files that you need to manually fix. After this "git rebase --continue".
But the output will tell you, what to do.

But again, your approach looks also fine.

Thanks,
Stefan

On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
>
> Thanks Daniel.
>
> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> > Hi Mauro,
> >
> > Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
> >> FYI
> >> I've been using this patchset for over a week without any adverse effect.
> >> It allowed me to port to VoCore2 board.
> >> Should I add a "Tested-by" flag?
> >> If so: how should I do it?
> >>
> >> Regards
> >> Mauro Codarelli
> >>
> > sorry that I could respond to your questions earlier. I've pushed the
> > complete patch set from Weijie to:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
> I tried to use this repo/branch, but something is wrong (or I goofed badly).
> > Maybe this helps you with development. If you have a bootable patch set
> > (you can do MMC later) for your VoCore2 board, please submit a regular
> > patch series based on that branch so that we can review again.
> I *do* have a bootable patchset built on top of master + Nemirovsky
> "reconfigurable cpu clocks" + Weijie v3.
> Result is fully working, including net and mmc/SD.
>
> This patchset applies cleanly to uboot-mips/testing and compile
> apparently without errors, but resulting u-boot.bin does not work.
> By "does not work" I mean it does not utter a single char on debug
> serial.
>
> I tried to do a complete diff between my working tree and this
> non-working one and there are tons of differences, but I couldn't
> spot anything that might be relevant.
>
> I am unsure on how to proceed; please advise.

but do you reach the U-Boot prompt? If I apply your patch and build
it, I need to be able to program the resulting U-Boot image to SPI
flash and boot to U-Boot prompt. Also note that the final U-Boot image
with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.

Regarding debug UART you also need to configure the serial driver with
"make menuconfig" (register base, clocks, baud rate etc.). There is no
driver model or device-tree involved at that point. I think Stefan
already told you the correct settings and you need this
board_early_init_f magic for the pinmux (don't forget to enable
CONFIG_BOARD_EARLY_INIT_F). But for the production mode debug UART
should be disabled anyway. SPL UART is different than debug UART.
AFAIU the regular driver model and device-tree stuff should work
there. For the pinmux you'll need the new CONFIG_SPL_UART2_SPIS_PINMUX
option. According to the code, you'll also need to configure
CONFIG_CONS_INDEX = 3.

On 11.02.20 14:54, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
>>
>> Thanks Daniel.
>>
>> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
>>> Hi Mauro,
>>>
>>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>>>> FYI
>>>> I've been using this patchset for over a week without any adverse effect.
>>>> It allowed me to port to VoCore2 board.
>>>> Should I add a "Tested-by" flag?
>>>> If so: how should I do it?
>>>>
>>>> Regards
>>>> Mauro Codarelli
>>>>
>>> sorry that I could respond to your questions earlier. I've pushed the
>>> complete patch set from Weijie to:
>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed badly).
>>> Maybe this helps you with development. If you have a bootable patch set
>>> (you can do MMC later) for your VoCore2 board, please submit a regular
>>> patch series based on that branch so that we can review again.
>> I *do* have a bootable patchset built on top of master + Nemirovsky
>> "reconfigurable cpu clocks" + Weijie v3.
>> Result is fully working, including net and mmc/SD.
>>
>> This patchset applies cleanly to uboot-mips/testing and compile
>> apparently without errors, but resulting u-boot.bin does not work.
>> By "does not work" I mean it does not utter a single char on debug
>> serial.
>>
>> I tried to do a complete diff between my working tree and this
>> non-working one and there are tons of differences, but I couldn't
>> spot anything that might be relevant.
>>
>> I am unsure on how to proceed; please advise.
> 
> but do you reach the U-Boot prompt? If I apply your patch and build
> it, I need to be able to program the resulting U-Boot image to SPI
> flash and boot to U-Boot prompt. Also note that the final U-Boot image
> with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.

A quick remark on this, as I've forgotten to write about this:

I would like to change the resulting image name from this specific
"u-boot-mips.bin" to the already known "u-boot-with-spl.bin" name.
There is no need to introduce a new name here and there is nothing
"mtmips" specific in this image type.

Thanks,
Stefan

Sorry Daniel,
I seem unable to pass the message through.

I have, in front of me two, very similar directories:

u-boot.master:
built from master + Weijie.v3 patches + my vocore2 patch.

u-boot-mips:
built from u-boot-mips/testing + my vocore2 patch.

I was very careful not to change anything after patching.

In both directories I do:

make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
make ARCH=mips CROSS_COMPILE=mipsel-linux-

Both produce similarly-sized u-boot-mtmips.bin (Flash version)
and u-boot.bin (RAM version).

On my target I do:

setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin; go
${fileaddr}

In the case of the "master dir I get:

=> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
DHCP client bound to address 192.168.7.135 (115 ms)
Using eth at 10110000 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.135
Filename 'u-boot.bin'.
Load address: 0x80200000
Loading: ####################################
     1.1 MiB/s
done
Bytes transferred = 527090 (80af2 hex)
## Starting application at 0x80200000 ...


U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc at 10130000: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:  
Warning: eth at 10110000 (eth0) using random MAC address - 26:9f:0f:24:ae:39
eth0: eth at 10110000
Hit any key to stop autoboot:  0
=>

If I do the same with product of "mips" dir I get:

=> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.112 (3136 ms)
Using eth at 10110000 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.112
Filename 'u-boot.bin'.
Load address: 0x80200000
Loading: ####################################
     1 MiB/s
done
Bytes transferred = 527390 (80c1e hex)
## Starting application at 0x80200000 ...
<*DEAD*>

I am trying to understand where difference lies... and failing, to date :(

I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
squashing the three commits in one, no change) earlier today;
if You think it might be useful I can send also the complete
"git format-patch" from a known u-boot master commit from
where I branched off
(currently 8b9cc858e0239823b051a9324431d511baf2b998)

My "git log --oneline" on "master" is:
c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
Move back environment to SPI NOR. Changes to environment default settings.
7dbd7fc8bc Added network setup.
375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
SoM "VoCore2".
f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
mt7628-rfb
724463aa9e mips: mtmips: enable SPL for all boards
1fe4eda6c3 mips: mtmips: add SPL support
5ea8181206 spl: nor: add lzma decompression support for legacy image
173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
e4721a8b98 lib: enable lzma decompression support for SPL build
b769d64488 mips: add an option to enable u_boot_list section for SPL
loaders in u-boot-spl.lds
c704313c7e mips: enable support for appending dtb to spl binary
8801d2b226 dts: mtmips: add alternative pinmux node for uart2
4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
13299d7651 mips: add a option to support not reserving malloc space on
initial stack
eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
global data
f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
mtmips boards
e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
58246e0175 sysreset: add reset controller based reboot driver
b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
global data in stack
c2359e8947 mips: add an option to support initialize SRAM for initial stack
a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
b096b2e05f mips: add support to restore exception vector base before
booting linux
2e5b1c00fd MIPS: allow override of get_tbclk()
8b9cc858e0 mx7ulp: Move SoC base address to a common file
...

while in the "mips" directory I have:
cd23ee2179 (HEAD -> VoCore2) Move back environment to SPI NOR. Changes
to environment default settings.
ddc07fb968 Added network setup.
9eabc0c0bb Add support for SoM "VoCore2".
b3d1d5d05b (origin/testing, testing, master) mips: mtmips: add support
for mt7628-rfb

As said: there must be some difference, somewhere,
but it's not evident (to me) where it is and how to find it.

Thanks in Advance for any advice
Best Regards
Mauro

On 2/11/20 2:54 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
>> Thanks Daniel.
>>
>> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
>>> Hi Mauro,
>>>
>>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>>>> FYI
>>>> I've been using this patchset for over a week without any adverse effect.
>>>> It allowed me to port to VoCore2 board.
>>>> Should I add a "Tested-by" flag?
>>>> If so: how should I do it?
>>>>
>>>> Regards
>>>> Mauro Codarelli
>>>>
>>> sorry that I could respond to your questions earlier. I've pushed the
>>> complete patch set from Weijie to:
>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed badly).
>>> Maybe this helps you with development. If you have a bootable patch set
>>> (you can do MMC later) for your VoCore2 board, please submit a regular
>>> patch series based on that branch so that we can review again.
>> I *do* have a bootable patchset built on top of master + Nemirovsky
>> "reconfigurable cpu clocks" + Weijie v3.
>> Result is fully working, including net and mmc/SD.
>>
>> This patchset applies cleanly to uboot-mips/testing and compile
>> apparently without errors, but resulting u-boot.bin does not work.
>> By "does not work" I mean it does not utter a single char on debug
>> serial.
>>
>> I tried to do a complete diff between my working tree and this
>> non-working one and there are tons of differences, but I couldn't
>> spot anything that might be relevant.
>>
>> I am unsure on how to proceed; please advise.
> but do you reach the U-Boot prompt? If I apply your patch and build
> it, I need to be able to program the resulting U-Boot image to SPI
> flash and boot to U-Boot prompt. Also note that the final U-Boot image
> with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.
>
> Regarding debug UART you also need to configure the serial driver with
> "make menuconfig" (register base, clocks, baud rate etc.). There is no
> driver model or device-tree involved at that point. I think Stefan
> already told you the correct settings and you need this
> board_early_init_f magic for the pinmux (don't forget to enable
> CONFIG_BOARD_EARLY_INIT_F). But for the production mode debug UART
> should be disabled anyway. SPL UART is different than debug UART.
> AFAIU the regular driver model and device-tree stuff should work
> there. For the pinmux you'll need the new CONFIG_SPL_UART2_SPIS_PINMUX
> option. According to the code, you'll also need to configure
> CONFIG_CONS_INDEX = 3.
>

On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli <mc5686 at mclink.it> wrote:
>
> Sorry Daniel,
> I seem unable to pass the message through.
>
> I have, in front of me two, very similar directories:
>
> u-boot.master:
> built from master + Weijie.v3 patches + my vocore2 patch.
>
> u-boot-mips:
> built from u-boot-mips/testing + my vocore2 patch.
>
> I was very careful not to change anything after patching.
>
> In both directories I do:
>
> make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
> make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
> make ARCH=mips CROSS_COMPILE=mipsel-linux-
>
> Both produce similarly-sized u-boot-mtmips.bin (Flash version)
> and u-boot.bin (RAM version).
>
> On my target I do:
>
> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin; go
> ${fileaddr}
>
> In the case of the "master dir I get:
>
> => setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> DHCP client bound to address 192.168.7.135 (115 ms)
> Using eth at 10110000 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.135
> Filename 'u-boot.bin'.
> Load address: 0x80200000
> Loading: ####################################
>      1.1 MiB/s
> done
> Bytes transferred = 527090 (80af2 hex)
> ## Starting application at 0x80200000 ...
>
>
> U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +0100)
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> Model: VoCore2
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc at 10130000: 0
> Loading Environment from SPI Flash... SF: Detected w25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> Model: VoCore2
> Net:
> Warning: eth at 10110000 (eth0) using random MAC address - 26:9f:0f:24:ae:39
> eth0: eth at 10110000
> Hit any key to stop autoboot:  0
> =>

ok, booting from RAM works. But what I meant with bootable is, that
you can write the
the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
can merge your patch.

>
> If I do the same with product of "mips" dir I get:
>
> => setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> DHCP client bound to address 192.168.7.112 (3136 ms)
> Using eth at 10110000 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.112
> Filename 'u-boot.bin'.
> Load address: 0x80200000
> Loading: ####################################
>      1 MiB/s
> done
> Bytes transferred = 527390 (80c1e hex)
> ## Starting application at 0x80200000 ...
> <*DEAD*>
>
> I am trying to understand where difference lies... and failing, to date :(
>
> I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
> squashing the three commits in one, no change) earlier today;
> if You think it might be useful I can send also the complete
> "git format-patch" from a known u-boot master commit from
> where I branched off
> (currently 8b9cc858e0239823b051a9324431d511baf2b998)
>
> My "git log --oneline" on "master" is:
> c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
> Move back environment to SPI NOR. Changes to environment default settings.
> 7dbd7fc8bc Added network setup.
> 375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
> SoM "VoCore2".
> f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
> mt7628-rfb
> 724463aa9e mips: mtmips: enable SPL for all boards
> 1fe4eda6c3 mips: mtmips: add SPL support
> 5ea8181206 spl: nor: add lzma decompression support for legacy image
> 173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
> 789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
> e4721a8b98 lib: enable lzma decompression support for SPL build
> b769d64488 mips: add an option to enable u_boot_list section for SPL
> loaders in u-boot-spl.lds
> c704313c7e mips: enable support for appending dtb to spl binary
> 8801d2b226 dts: mtmips: add alternative pinmux node for uart2
> 4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
> 13299d7651 mips: add a option to support not reserving malloc space on
> initial stack
> eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
> global data
> f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
> mtmips boards
> e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
> 58246e0175 sysreset: add reset controller based reboot driver
> b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
> global data in stack
> c2359e8947 mips: add an option to support initialize SRAM for initial stack
> a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
> b096b2e05f mips: add support to restore exception vector base before
> booting linux
> 2e5b1c00fd MIPS: allow override of get_tbclk()
> 8b9cc858e0 mx7ulp: Move SoC base address to a common file
> ...
>
> while in the "mips" directory I have:
> cd23ee2179 (HEAD -> VoCore2) Move back environment to SPI NOR. Changes
> to environment default settings.
> ddc07fb968 Added network setup.
> 9eabc0c0bb Add support for SoM "VoCore2".
> b3d1d5d05b (origin/testing, testing, master) mips: mtmips: add support
> for mt7628-rfb
>
> As said: there must be some difference, somewhere,
> but it's not evident (to me) where it is and how to find it.
>
> Thanks in Advance for any advice
> Best Regards
> Mauro
>
> On 2/11/20 2:54 PM, Daniel Schwierzeck wrote:
> > On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
> >> Thanks Daniel.
> >>
> >> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> >>> Hi Mauro,
> >>>
> >>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
> >>>> FYI
> >>>> I've been using this patchset for over a week without any adverse effect.
> >>>> It allowed me to port to VoCore2 board.
> >>>> Should I add a "Tested-by" flag?
> >>>> If so: how should I do it?
> >>>>
> >>>> Regards
> >>>> Mauro Codarelli
> >>>>
> >>> sorry that I could respond to your questions earlier. I've pushed the
> >>> complete patch set from Weijie to:
> >>>
> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
> >> I tried to use this repo/branch, but something is wrong (or I goofed badly).
> >>> Maybe this helps you with development. If you have a bootable patch set
> >>> (you can do MMC later) for your VoCore2 board, please submit a regular
> >>> patch series based on that branch so that we can review again.
> >> I *do* have a bootable patchset built on top of master + Nemirovsky
> >> "reconfigurable cpu clocks" + Weijie v3.
> >> Result is fully working, including net and mmc/SD.
> >>
> >> This patchset applies cleanly to uboot-mips/testing and compile
> >> apparently without errors, but resulting u-boot.bin does not work.
> >> By "does not work" I mean it does not utter a single char on debug
> >> serial.
> >>
> >> I tried to do a complete diff between my working tree and this
> >> non-working one and there are tons of differences, but I couldn't
> >> spot anything that might be relevant.
> >>
> >> I am unsure on how to proceed; please advise.

maybe you have a big diff because you are not on the latest master
branch. I currently
have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based
on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
to 20/20. For
u-boot-mips/next I intend to create a pull request soon. The existing
mtmips boards should
still work without SPL support. Maybe Stefan could give it a quick test.

Maybe I messed something up in u-boot-mips/testing. There were some
merge conflicts.
Could you build a new patch queue on top of u-boot-mips/next with the remaining
Weijie v3 patches and your VoCore2 patches?

As long as all u-boot-mips changes aren't merged to mainline, your
patches must work with
the latest u-boot-mips/next branch. There could always be new and
incompatible changes
in mainline or in other MIPS patches which you have to figure out then.

Thanks Daniel.

On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli <mc5686 at mclink.it> wrote:
>> ===8<----
>> Hit any key to stop autoboot:  0
>> =>
> ok, booting from RAM works. But what I meant with bootable is, that
> you can write the
> the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
> can merge your patch.
It *does* work.
The U-Boot I have flashed is essentially the same as the one built
in the "master" directory, just a few days old (I changed essentially
my project-specific CONFIG_EXTRA_ENV_SETTINGS).

... which reminds me of something...

... it turns out that flashing *does* work:

=> setenv autoload no; dhcp; tftpboot 85000000
192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
${filesize}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.110 (2953 ms)
Using eth at 10110000 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.110
Filename 'u-boot-mtmips.bin'.
Load address: 0x85000000
Loading: #################
     762.7 KiB/s
done
Bytes transferred = 244458 (3baea hex)
device 0 offset 0x0, size 0x3baea
240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
=> reset
resetting ...

U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
Trying to boot from NOR


U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc at 10130000: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:  
Warning: eth at 10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
eth0: eth at 10110000
Hit any key to stop autoboot:  0
=>

What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same location
(80200000) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.

Now that I reflashed "u-boot-mips/testing" version I can run it also
"from RAM", while trying to load "master" hangs (I tried just now).

If this is considered "acceptable" (probably it has nothing to do with my
vocore2 port) I can clean-up my patches and resubmit.
I'm not a mips expert and I don't know how to debug this "RAM load"
misbehavior, but I'm available for testing, if useful.


>> ===8<---
>>>> I *do* have a bootable patchset built on top of master + Nemirovsky
>>>> "reconfigurable cpu clocks" + Weijie v3.
>>>> Result is fully working, including net and mmc/SD.
>>>>
>>>> This patchset applies cleanly to uboot-mips/testing and compile
>>>> apparently without errors, but resulting u-boot.bin does not work.
>>>> By "does not work" I mean it does not utter a single char on debug
>>>> serial.
>>>>
>>>> I tried to do a complete diff between my working tree and this
>>>> non-working one and there are tons of differences, but I couldn't
>>>> spot anything that might be relevant.
>>>>
>>>> I am unsure on how to proceed; please advise.
> maybe you have a big diff because you are not on the latest master
> branch. I currently
> have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based
> on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
> to 20/20. For
> u-boot-mips/next I intend to create a pull request soon. The existing
> mtmips boards should
> still work without SPL support. Maybe Stefan could give it a quick test.
>
> Maybe I messed something up in u-boot-mips/testing. There were some
> merge conflicts.
I don't think so.
As said problem is with RAM loading.

> Could you build a new patch queue on top of u-boot-mips/next with the remaining
> Weijie v3 patches and your VoCore2 patches?
I can do that if You think it's still useful, otherwise we can
just use testing.

> As long as all u-boot-mips changes aren't merged to mainline, your
> patches must work with
> the latest u-boot-mips/next branch. There could always be new and
> incompatible changes
Understood.

> in mainline or in other MIPS patches which you have to figure out then.
I don't think  there'll be problems.
My patches are quite basic and board-only.

I plan to clean my patch expunging all project-specific stuff,
rebase from the (current) tip of uboot-mips-mips/testing and
resubmit (unless You tell me to do something different,
of course).

For the Ram-lading problem I do not currently plan any
action, but I'm available.

Best Regards (and pardon me for the noise, please)
Mauro Condarelli

Hi Mauro,
Hi Daniel,

On 11.02.20 19:05, Mauro Condarelli wrote:
> Thanks Daniel.
> 
> On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
>> On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli <mc5686 at mclink.it> wrote:
>>> ===8<----
>>> Hit any key to stop autoboot:  0
>>> =>
>> ok, booting from RAM works. But what I meant with bootable is, that
>> you can write the
>> the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
>> can merge your patch.
> It *does* work.
> The U-Boot I have flashed is essentially the same as the one built
> in the "master" directory, just a few days old (I changed essentially
> my project-specific CONFIG_EXTRA_ENV_SETTINGS).
> 
> ... which reminds me of something...
> 
> ... it turns out that flashing *does* work:
> 
> => setenv autoload no; dhcp; tftpboot 85000000
> 192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
> ${filesize}
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> DHCP client bound to address 192.168.7.110 (2953 ms)
> Using eth at 10110000 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.110
> Filename 'u-boot-mtmips.bin'.
> Load address: 0x85000000
> Loading: #################
>       762.7 KiB/s
> done
> Bytes transferred = 244458 (3baea hex)
> device 0 offset 0x0, size 0x3baea
> 240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
> => reset
> resetting ...
> 
> U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
> Trying to boot from NOR
> 
> 
> U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
> 
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> Model: VoCore2
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc at 10130000: 0
> Loading Environment from SPI Flash... SF: Detected w25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> Model: VoCore2
> Net:
> Warning: eth at 10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
> eth0: eth at 10110000
> Hit any key to stop autoboot:  0
> =>
> 
> What *does NOT* work is loading RAM version or, to be more precise:
> It works IF (and only if) you load the same code already running.
> I *think* this is because current Weijie code unpacks to this same location
> (80200000) before relocating. If you are rewriting the same code in the
> same location any cache inconsistencies are unimportant, otherwise
> Bad Things happen.
> I spoke with Stephan about this, but we never found a fix.
> 
> Now that I reflashed "u-boot-mips/testing" version I can run it also
> "from RAM", while trying to load "master" hangs (I tried just now).
> 
> If this is considered "acceptable" (probably it has nothing to do with my
> vocore2 port) I can clean-up my patches and resubmit.
> I'm not a mips expert and I don't know how to debug this "RAM load"
> misbehavior, but I'm available for testing, if useful.

I also noticed that "RAM loading" the U-Boot proper does not work all
the time on my MT7688 targets. It seems to depend on the image size
and some other factors (moon phase...). ;)

So there is very likely a bug somewhere hidden - perhaps in the
relocaton code. I will probably try to dig into this in sometime soon.
But I need a reproducable "bad" image for this. Right now, RAM loading
is working just fine.

BTW: I noticed that RAM loading does work even when loading into a
different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
0x80200000 and loadind to e.g. 0x81000000 does also work.

Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
independant?

Mauro, please try loading into a different address on your non-working
setup and report back if RAM loading works in this case.

> 
>>> ===8<---
>>>>> I *do* have a bootable patchset built on top of master + Nemirovsky
>>>>> "reconfigurable cpu clocks" + Weijie v3.
>>>>> Result is fully working, including net and mmc/SD.
>>>>>
>>>>> This patchset applies cleanly to uboot-mips/testing and compile
>>>>> apparently without errors, but resulting u-boot.bin does not work.
>>>>> By "does not work" I mean it does not utter a single char on debug
>>>>> serial.
>>>>>
>>>>> I tried to do a complete diff between my working tree and this
>>>>> non-working one and there are tons of differences, but I couldn't
>>>>> spot anything that might be relevant.
>>>>>
>>>>> I am unsure on how to proceed; please advise.
>> maybe you have a big diff because you are not on the latest master
>> branch. I currently
>> have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based
>> on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
>> to 20/20. For
>> u-boot-mips/next I intend to create a pull request soon. The existing
>> mtmips boards should
>> still work without SPL support. Maybe Stefan could give it a quick test.
>>
>> Maybe I messed something up in u-boot-mips/testing. There were some
>> merge conflicts.
> I don't think so.
> As said problem is with RAM loading.

I also have this problem (sometimes). Please see above.

>> Could you build a new patch queue on top of u-boot-mips/next with the remaining
>> Weijie v3 patches and your VoCore2 patches?
> I can do that if You think it's still useful, otherwise we can
> just use testing.
> 
>> As long as all u-boot-mips changes aren't merged to mainline, your
>> patches must work with
>> the latest u-boot-mips/next branch. There could always be new and
>> incompatible changes
> Understood.
> 
>> in mainline or in other MIPS patches which you have to figure out then.
> I don't think  there'll be problems.
> My patches are quite basic and board-only.
> 
> I plan to clean my patch expunging all project-specific stuff,
> rebase from the (current) tip of uboot-mips-mips/testing and
> resubmit (unless You tell me to do something different,
> of course).
> 
> For the Ram-lading problem I do not currently plan any
> action, but I'm available.

A test with a different load address would be interesting.

Thanks,
Stefan

Hi Stefan,
Hi Daniel,

On 2/12/20 7:39 AM, Stefan wrote:
> Hi Mauro,
> Hi Daniel,
>
> On 11.02.20 19:05, Mauro Condarelli wrote:
>> ===8<---
>>
>> What *does NOT* work is loading RAM version or, to be more precise:
>> It works IF (and only if) you load the same code already running.
>> I *think* this is because current Weijie code unpacks to this same
>> location
>> (80200000) before relocating. If you are rewriting the same code in the
>> same location any cache inconsistencies are unimportant, otherwise
>> Bad Things happen.
>> I spoke with Stephan about this, but we never found a fix.
>>
>> ===8<---
>
> I also noticed that "RAM loading" the U-Boot proper does not work all
> the time on my MT7688 targets. It seems to depend on the image size
> and some other factors (moon phase...). ;)
>
> So there is very likely a bug somewhere hidden - perhaps in the
> relocaton code. I will probably try to dig into this in sometime soon.
> But I need a reproducable "bad" image for this. Right now, RAM loading
> is working just fine.
As said: In my setup RAM loading is consistently failing if I try to load
an u-boot build consistently different from the one currently running.
OTOH loading the same (or very similar, a rebuild is considered "the
same") version is _always_ working for me.

To rephrase: I have two setups; one based on master+weijiev3 and
the other based on plain mtmips/testing.
I can flash either one and it works from SPI NOR. no problems here.
I can always RAM load successfully the same kernel as flashed.
If I RAM load the "other" setup it always fails.

I did a few tests:
- erasing download area (mw.b 80200000 0 80000).
- do some other loading (e.g.: the Linux kernel) between RAM load and
"go" (attempt to clean caches, but I suspect this would only effectively
clear D-cache, not I-cache).
The above behavior does not change.

>
> BTW: I noticed that RAM loading does work even when loading into a
> different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
> 0x80200000 and loadind to e.g. 0x81000000 does also work.
I do confirm this:
  setenv autoload no; dhcp; tftpboot 81000000
192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
works as expected (loading  same-as-flashed)

>
> Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
> independant?
>
> Mauro, please try loading into a different address on your non-working
> setup and report back if RAM loading works in this case.
Attempt to load, even at different address, the "other" u-boot fails:
  setenv autoload no; dhcp; tftpboot 81000000
192.168.7.101:u-boot.bin-weijie.v3.vocore2; go ${fileaddr}
hangs after "## Starting application at 0x81000000 ..." (I currently have
in SPI NOR the u-boot-mtmips.bin-mips.testing built together
u-boot.bin-mips.testing).

>> ===8<---
>> I don't think so.
>> As said problem is with RAM loading.
>
> I also have this problem (sometimes). Please see above.
>
>> ===8<---
>> For the Ram-lading problem I do not currently plan any
>> action, but I'm available.
>
> A test with a different load address would be interesting.
Done (see above).
Tell me if You want me to rebuild with a different TEXT_BASE
and test that.

>
> Thanks,
> Stefan
Regards
Mauro

Hi Mauro,

On 12.02.20 10:23, Mauro Condarelli wrote:
> Hi Stefan,
> Hi Daniel,
> 
> On 2/12/20 7:39 AM, Stefan wrote:
>> Hi Mauro,
>> Hi Daniel,
>>
>> On 11.02.20 19:05, Mauro Condarelli wrote:
>>> ===8<---
>>>
>>> What *does NOT* work is loading RAM version or, to be more precise:
>>> It works IF (and only if) you load the same code already running.
>>> I *think* this is because current Weijie code unpacks to this same
>>> location
>>> (80200000) before relocating. If you are rewriting the same code in the
>>> same location any cache inconsistencies are unimportant, otherwise
>>> Bad Things happen.
>>> I spoke with Stephan about this, but we never found a fix.
>>>
>>> ===8<---
>>
>> I also noticed that "RAM loading" the U-Boot proper does not work all
>> the time on my MT7688 targets. It seems to depend on the image size
>> and some other factors (moon phase...). ;)
>>
>> So there is very likely a bug somewhere hidden - perhaps in the
>> relocaton code. I will probably try to dig into this in sometime soon.
>> But I need a reproducable "bad" image for this. Right now, RAM loading
>> is working just fine.
> As said: In my setup RAM loading is consistently failing if I try to load
> an u-boot build consistently different from the one currently running.
> OTOH loading the same (or very similar, a rebuild is considered "the
> same") version is _always_ working for me.
> 
> To rephrase: I have two setups; one based on master+weijiev3 and
> the other based on plain mtmips/testing.
> I can flash either one and it works from SPI NOR. no problems here.
> I can always RAM load successfully the same kernel as flashed.
> If I RAM load the "other" setup it always fails.
> 
> I did a few tests:
> - erasing download area (mw.b 80200000 0 80000).
> - do some other loading (e.g.: the Linux kernel) between RAM load and
> "go" (attempt to clean caches, but I suspect this would only effectively
> clear D-cache, not I-cache).
> The above behavior does not change.
> 
>>
>> BTW: I noticed that RAM loading does work even when loading into a
>> different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
>> 0x80200000 and loadind to e.g. 0x81000000 does also work.
> I do confirm this:
>    setenv autoload no; dhcp; tftpboot 81000000
> 192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
> works as expected (loading  same-as-flashed)
> 
>>
>> Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
>> independant?
>>
>> Mauro, please try loading into a different address on your non-working
>> setup and report back if RAM loading works in this case.
> Attempt to load, even at different address, the "other" u-boot fails:
>    setenv autoload no; dhcp; tftpboot 81000000
> 192.168.7.101:u-boot.bin-weijie.v3.vocore2; go ${fileaddr}
> hangs after "## Starting application at 0x81000000 ..." (I currently have
> in SPI NOR the u-boot-mtmips.bin-mips.testing built together
> u-boot.bin-mips.testing).

Could you please apply the new cmd/boot.c patch I've sent just a few
minutes ago [1] and burn this image into flash. And please test with
this image, if RAM booting of other, different images does work for you
now.

And sorry, using a different TEXT_BASE does not seem to work. Somehow
I seem to have goofed up this morning in my tests. Please use always the
correct TEXT_BASE as load address for the RAM image.

Thanks,
Stefan

[1] http://patchwork.ozlabs.org/patch/1236810/

On Wed, Feb 12, 2020 at 10:23 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
>
> Hi Stefan,
> Hi Daniel,
>
> On 2/12/20 7:39 AM, Stefan wrote:
> > Hi Mauro,
> > Hi Daniel,
> >
> > On 11.02.20 19:05, Mauro Condarelli wrote:
> >> ===8<---
> >>
> >> What *does NOT* work is loading RAM version or, to be more precise:
> >> It works IF (and only if) you load the same code already running.
> >> I *think* this is because current Weijie code unpacks to this same
> >> location
> >> (80200000) before relocating. If you are rewriting the same code in the
> >> same location any cache inconsistencies are unimportant, otherwise
> >> Bad Things happen.
> >> I spoke with Stephan about this, but we never found a fix.
> >>
> >> ===8<---
> >
> > I also noticed that "RAM loading" the U-Boot proper does not work all
> > the time on my MT7688 targets. It seems to depend on the image size
> > and some other factors (moon phase...). ;)
> >
> > So there is very likely a bug somewhere hidden - perhaps in the
> > relocaton code. I will probably try to dig into this in sometime soon.
> > But I need a reproducable "bad" image for this. Right now, RAM loading
> > is working just fine.
> As said: In my setup RAM loading is consistently failing if I try to load
> an u-boot build consistently different from the one currently running.
> OTOH loading the same (or very similar, a rebuild is considered "the
> same") version is _always_ working for me.
>
> To rephrase: I have two setups; one based on master+weijiev3 and
> the other based on plain mtmips/testing.
> I can flash either one and it works from SPI NOR. no problems here.
> I can always RAM load successfully the same kernel as flashed.
> If I RAM load the "other" setup it always fails.
>
> I did a few tests:
> - erasing download area (mw.b 80200000 0 80000).
> - do some other loading (e.g.: the Linux kernel) between RAM load and
> "go" (attempt to clean caches, but I suspect this would only effectively
> clear D-cache, not I-cache).
> The above behavior does not change.
>
> >
> > BTW: I noticed that RAM loading does work even when loading into a
> > different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
> > 0x80200000 and loadind to e.g. 0x81000000 does also work.
> I do confirm this:
>   setenv autoload no; dhcp; tftpboot 81000000
> 192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
> works as expected (loading  same-as-flashed)
>
> >
> > Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
> > independant?

from your tests I can only conclude that RAM loading doesn't work at
all. If you see it
"working" than you simply junp to the old copy which the SPL created.
A MIPS U-Boot
is always built with position-dependant code. To make the U-Boot
binary relocatable,
we use the tools/mips-relocs.c which was ported from Linux. During
linking we let gcc
emit relocation entries which are post-processed by the mips-relocs
tool. The output
is then inserted into u-boot.bin in section ".data.reloc". Those reloc
entries are then
used by the MIPS relocation code to patch all symbols with the
relative offset to the
new text address.

If you build for example the Gardena Smart Gateway and disassemble the u-boot
binary (which becomes the SPL payload), the very first instruction is this:

80200000 <_start>:
#endif
        .endm

ENTRY(_start)
        /* U-Boot entry point */
        b       reset
80200000:       1000013f        b       80200500 <reset>
         mtc0   zero, CP0_COUNT # clear cp0 count for most accurate boot timing
80200004:       40804800        mtc0    zero,c0_count

So if you load u-boot.bin to a different address than 0x80200000 and jump to it,
the first instruction is a jump back to address 0x80200500. If the old SPL copy
of u-boot.bin is still there, you'll see a "working" RAM boot.

Actually Mauro already did the right thing with erasing the load area
at 0x80200000
before downloading a new binary.

A stable approach to a RAM boot binary (which I use in my out-of-tree boards)
would be to use a KSEG1 text address e.g. 0xa0200000 and explicitely switch
the CPU to non-caching mode (this is normally skipped with
CONFIG_SKIP_LOWLEVEL_INIT in the SPL payload). This approach always worked
for me for booting via UART or EJTAG without getting messed up by
cache effects.

So either we officially drop RAM boot support for mtmips platform (respectively
don't use the u-boot.bin intended for SPL payload as RAM boot binary)
or we keep the
special RAM boot configs.

Hi Daniel,

On 12.02.20 13:48, Daniel Schwierzeck wrote:

<snip>

>>> Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
>>> independant?
> 
> from your tests I can only conclude that RAM loading doesn't work at
> all. If you see it
> "working" than you simply junp to the old copy which the SPL created.
> A MIPS U-Boot
> is always built with position-dependant code. To make the U-Boot
> binary relocatable,
> we use the tools/mips-relocs.c which was ported from Linux. During
> linking we let gcc
> emit relocation entries which are post-processed by the mips-relocs
> tool. The output
> is then inserted into u-boot.bin in section ".data.reloc". Those reloc
> entries are then
> used by the MIPS relocation code to patch all symbols with the
> relative offset to the
> new text address.
> 
> If you build for example the Gardena Smart Gateway and disassemble the u-boot
> binary (which becomes the SPL payload), the very first instruction is this:
> 
> 80200000 <_start>:
> #endif
>          .endm
> 
> ENTRY(_start)
>          /* U-Boot entry point */
>          b       reset
> 80200000:       1000013f        b       80200500 <reset>
>           mtc0   zero, CP0_COUNT # clear cp0 count for most accurate boot timing
> 80200004:       40804800        mtc0    zero,c0_count
> 
> So if you load u-boot.bin to a different address than 0x80200000 and jump to it,
> the first instruction is a jump back to address 0x80200500. If the old SPL copy
> of u-boot.bin is still there, you'll see a "working" RAM boot.

Thanks for this analysis. This is exactly what happened in my test this
morning.

> Actually Mauro already did the right thing with erasing the load area
> at 0x80200000
> before downloading a new binary.
> 
> A stable approach to a RAM boot binary (which I use in my out-of-tree boards)
> would be to use a KSEG1 text address e.g. 0xa0200000 and explicitely switch
> the CPU to non-caching mode (this is normally skipped with
> CONFIG_SKIP_LOWLEVEL_INIT in the SPL payload). This approach always worked
> for me for booting via UART or EJTAG without getting messed up by
> cache effects.
> 
> So either we officially drop RAM boot support for mtmips platform (respectively
> don't use the u-boot.bin intended for SPL payload as RAM boot binary)
> or we keep the
> special RAM boot configs.

I assume that you are also okay with the cache flush approach? I'll send
v2 of this patch pretty soon if nobody objects.

Thanks,
Stefan