[PATCH v3 00/20] Refactor the architecture parts of mt7628
This patch series are divided into two parts:
The main part is to rewrite the whole architecture code of mt7628: * Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C. * Memory controller & DDR initialization have been fully written to support detecting DDR size automatically. * DDR calibration has also been reimplemented with a clear logic. * Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size.
The second part is to add SPL support for mt7628: * With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files. * Generate compressed u-boot.bin image for SPL to reduce size of final combined binary. * Enable DM support for SPL for a more flexible device probing. * Add a demo board (mt7628_rfb) aims at router application.
Changes since v2: * Dropped a patch which removes unused parts of mt7628a.dtsi * Move lzma decompression support to common spl_nor.c * Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
Makefile | 22 ++ arch/mips/Kconfig | 66 ++++ arch/mips/cpu/start.S | 16 +- arch/mips/cpu/u-boot-spl.lds | 4 +- arch/mips/dts/Makefile | 1 + arch/mips/dts/mediatek,mt7628-rfb.dts | 67 ++++ arch/mips/dts/mt7628-u-boot.dtsi | 56 +++ arch/mips/dts/mt7628a.dtsi | 17 +- arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/u-boot-mips.h | 2 + arch/mips/lib/bootm.c | 3 + arch/mips/lib/traps.c | 19 + arch/mips/mach-mtmips/Kconfig | 132 +++---- arch/mips/mach-mtmips/Makefile | 8 +- arch/mips/mach-mtmips/cpu.c | 58 +--- arch/mips/mach-mtmips/ddr_cal.c | 211 +++++++++++ arch/mips/mach-mtmips/ddr_calibrate.c | 309 ----------------- arch/mips/mach-mtmips/ddr_init.c | 194 +++++++++++ arch/mips/mach-mtmips/include/mach/ddr.h | 52 +++ arch/mips/mach-mtmips/include/mach/mc.h | 180 ++++++++++ arch/mips/mach-mtmips/include/mach/serial.h | 13 + arch/mips/mach-mtmips/lowlevel_init.S | 328 ------------------ arch/mips/mach-mtmips/mt7628/Makefile | 6 + arch/mips/mach-mtmips/mt7628/ddr.c | 173 +++++++++ arch/mips/mach-mtmips/mt7628/init.c | 109 ++++++ arch/mips/mach-mtmips/mt7628/lowlevel_init.S | 161 +++++++++ arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++++++ arch/mips/mach-mtmips/mt7628/serial.c | 34 ++ arch/mips/mach-mtmips/mt76xx.h | 32 -- arch/mips/mach-mtmips/spl.c | 44 +++ board/gardena/smart-gateway-mt7688/board.c | 2 + board/mediatek/mt7628/Kconfig | 12 + board/mediatek/mt7628/MAINTAINERS | 7 + board/mediatek/mt7628/Makefile | 3 + board/mediatek/mt7628/board.c | 8 + common/spl/spl_nor.c | 59 +++- ...gardena-smart-gateway-mt7688-ram_defconfig | 74 ---- .../gardena-smart-gateway-mt7688_defconfig | 16 +- configs/linkit-smart-7688-ram_defconfig | 65 ---- configs/linkit-smart-7688_defconfig | 16 +- configs/mt7628_rfb_defconfig | 46 +++ drivers/sysreset/Kconfig | 6 + drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_resetctl.c | 48 +++ .../configs/gardena-smart-gateway-mt7688.h | 20 +- include/configs/linkit-smart-7688.h | 21 +- include/configs/mt7628.h | 55 +++ lib/Kconfig | 5 + lib/Makefile | 1 + tools/binman/README.entries | 15 + tools/binman/etype/u_boot_lzma_img.py | 28 ++ 51 files changed, 1952 insertions(+), 980 deletions(-) create mode 100644 arch/mips/dts/mediatek,mt7628-rfb.dts create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi create mode 100644 arch/mips/mach-mtmips/ddr_cal.c delete mode 100644 arch/mips/mach-mtmips/ddr_calibrate.c create mode 100644 arch/mips/mach-mtmips/ddr_init.c create mode 100644 arch/mips/mach-mtmips/include/mach/ddr.h create mode 100644 arch/mips/mach-mtmips/include/mach/mc.h create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h delete mode 100644 arch/mips/mach-mtmips/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/Makefile create mode 100644 arch/mips/mach-mtmips/mt7628/ddr.c create mode 100644 arch/mips/mach-mtmips/mt7628/init.c create mode 100644 arch/mips/mach-mtmips/mt7628/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/mt7628.h create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c delete mode 100644 arch/mips/mach-mtmips/mt76xx.h create mode 100644 arch/mips/mach-mtmips/spl.c create mode 100644 board/mediatek/mt7628/Kconfig create mode 100644 board/mediatek/mt7628/MAINTAINERS create mode 100644 board/mediatek/mt7628/Makefile create mode 100644 board/mediatek/mt7628/board.c delete mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig delete mode 100644 configs/linkit-smart-7688-ram_defconfig create mode 100644 configs/mt7628_rfb_defconfig create mode 100644 drivers/sysreset/sysreset_resetctl.c create mode 100644 include/configs/mt7628.h create mode 100644 tools/binman/etype/u_boot_lzma_img.py
I'm having a holiday from tomorrow to Jan 30th and I may not reply during the holiday.
Sincerely
On Tue, 2020-01-21 at 16:17 +0800, Weijie Gao wrote:
This patch series are divided into two parts:
The main part is to rewrite the whole architecture code of mt7628:
- Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C.
- Memory controller & DDR initialization have been fully written to support detecting DDR size automatically.
- DDR calibration has also been reimplemented with a clear logic.
- Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size.
The second part is to add SPL support for mt7628:
- With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files.
- Generate compressed u-boot.bin image for SPL to reduce size of final combined binary.
- Enable DM support for SPL for a more flexible device probing.
- Add a demo board (mt7628_rfb) aims at router application.
Changes since v2:
- Dropped a patch which removes unused parts of mt7628a.dtsi
- Move lzma decompression support to common spl_nor.c
- Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
Makefile | 22 ++ arch/mips/Kconfig | 66 ++++ arch/mips/cpu/start.S | 16 +- arch/mips/cpu/u-boot-spl.lds | 4 +- arch/mips/dts/Makefile | 1 + arch/mips/dts/mediatek,mt7628-rfb.dts | 67 ++++ arch/mips/dts/mt7628-u-boot.dtsi | 56 +++ arch/mips/dts/mt7628a.dtsi | 17 +- arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/u-boot-mips.h | 2 + arch/mips/lib/bootm.c | 3 + arch/mips/lib/traps.c | 19 + arch/mips/mach-mtmips/Kconfig | 132 +++---- arch/mips/mach-mtmips/Makefile | 8 +- arch/mips/mach-mtmips/cpu.c | 58 +--- arch/mips/mach-mtmips/ddr_cal.c | 211 +++++++++++ arch/mips/mach-mtmips/ddr_calibrate.c | 309 ----------------- arch/mips/mach-mtmips/ddr_init.c | 194 +++++++++++ arch/mips/mach-mtmips/include/mach/ddr.h | 52 +++ arch/mips/mach-mtmips/include/mach/mc.h | 180 ++++++++++ arch/mips/mach-mtmips/include/mach/serial.h | 13 + arch/mips/mach-mtmips/lowlevel_init.S | 328 ------------------ arch/mips/mach-mtmips/mt7628/Makefile | 6 + arch/mips/mach-mtmips/mt7628/ddr.c | 173 +++++++++ arch/mips/mach-mtmips/mt7628/init.c | 109 ++++++ arch/mips/mach-mtmips/mt7628/lowlevel_init.S | 161 +++++++++ arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++++++ arch/mips/mach-mtmips/mt7628/serial.c | 34 ++ arch/mips/mach-mtmips/mt76xx.h | 32 -- arch/mips/mach-mtmips/spl.c | 44 +++ board/gardena/smart-gateway-mt7688/board.c | 2 + board/mediatek/mt7628/Kconfig | 12 + board/mediatek/mt7628/MAINTAINERS | 7 + board/mediatek/mt7628/Makefile | 3 + board/mediatek/mt7628/board.c | 8 + common/spl/spl_nor.c | 59 +++- ...gardena-smart-gateway-mt7688-ram_defconfig | 74 ---- .../gardena-smart-gateway-mt7688_defconfig | 16 +- configs/linkit-smart-7688-ram_defconfig | 65 ---- configs/linkit-smart-7688_defconfig | 16 +- configs/mt7628_rfb_defconfig | 46 +++ drivers/sysreset/Kconfig | 6 + drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_resetctl.c | 48 +++ .../configs/gardena-smart-gateway-mt7688.h | 20 +- include/configs/linkit-smart-7688.h | 21 +- include/configs/mt7628.h | 55 +++ lib/Kconfig | 5 + lib/Makefile | 1 + tools/binman/README.entries | 15 + tools/binman/etype/u_boot_lzma_img.py | 28 ++ 51 files changed, 1952 insertions(+), 980 deletions(-) create mode 100644 arch/mips/dts/mediatek,mt7628-rfb.dts create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi create mode 100644 arch/mips/mach-mtmips/ddr_cal.c delete mode 100644 arch/mips/mach-mtmips/ddr_calibrate.c create mode 100644 arch/mips/mach-mtmips/ddr_init.c create mode 100644 arch/mips/mach-mtmips/include/mach/ddr.h create mode 100644 arch/mips/mach-mtmips/include/mach/mc.h create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h delete mode 100644 arch/mips/mach-mtmips/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/Makefile create mode 100644 arch/mips/mach-mtmips/mt7628/ddr.c create mode 100644 arch/mips/mach-mtmips/mt7628/init.c create mode 100644 arch/mips/mach-mtmips/mt7628/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/mt7628.h create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c delete mode 100644 arch/mips/mach-mtmips/mt76xx.h create mode 100644 arch/mips/mach-mtmips/spl.c create mode 100644 board/mediatek/mt7628/Kconfig create mode 100644 board/mediatek/mt7628/MAINTAINERS create mode 100644 board/mediatek/mt7628/Makefile create mode 100644 board/mediatek/mt7628/board.c delete mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig delete mode 100644 configs/linkit-smart-7688-ram_defconfig create mode 100644 configs/mt7628_rfb_defconfig create mode 100644 drivers/sysreset/sysreset_resetctl.c create mode 100644 include/configs/mt7628.h create mode 100644 tools/binman/etype/u_boot_lzma_img.py
Hi Weije,
Am 21.01.20 um 09:17 schrieb Weijie Gao:
This patch series are divided into two parts:
The main part is to rewrite the whole architecture code of mt7628:
- Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C.
- Memory controller & DDR initialization have been fully written to support detecting DDR size automatically.
- DDR calibration has also been reimplemented with a clear logic.
- Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size.
The second part is to add SPL support for mt7628:
- With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files.
- Generate compressed u-boot.bin image for SPL to reduce size of final combined binary.
- Enable DM support for SPL for a more flexible device probing.
- Add a demo board (mt7628_rfb) aims at router application.
Changes since v2:
- Dropped a patch which removes unused parts of mt7628a.dtsi
- Move lzma decompression support to common spl_nor.c
- Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
could you resend patches from 14/20 to 20/20? Patch 16/20 should get a test as requested by Simon. From the remaining generic patches I'd like to have some more acks before applying. Thanks.
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
On 2/10/20 6:20 PM, Daniel Schwierzeck wrote:
Hi Weije,
Am 21.01.20 um 09:17 schrieb Weijie Gao:
This patch series are divided into two parts:
The main part is to rewrite the whole architecture code of mt7628:
- Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C.
- Memory controller & DDR initialization have been fully written to support detecting DDR size automatically.
- DDR calibration has also been reimplemented with a clear logic.
- Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size.
The second part is to add SPL support for mt7628:
- With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files.
- Generate compressed u-boot.bin image for SPL to reduce size of final combined binary.
- Enable DM support for SPL for a more flexible device probing.
- Add a demo board (mt7628_rfb) aims at router application.
Changes since v2:
- Dropped a patch which removes unused parts of mt7628a.dtsi
- Move lzma decompression support to common spl_nor.c
- Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
could you resend patches from 14/20 to 20/20? Patch 16/20 should get a test as requested by Simon. From the remaining generic patches I'd like to have some more acks before applying. Thanks.
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
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.
Regarding the Tested-by, simply respond to a patch mail with a
Tested-by: Mauro Condarelli mc5686@mclink.it
Then Patchwork will record that and automatically adds this line to the patch when I download it. Personally I always remove all parts of the mail beginning with the first "diff --git a/...." when I send a Tested-by or Reviewed-by.
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. ==========================================
From f1828bcacbd3fc3bc8aa9243b302ab2b7a509d88 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli mc5686@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@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@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@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@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@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@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "jedec,spi-nor"; + spi-max-frequency = <25000000>; + reg = <0>; + }; +}; + +ð { + 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@mclink.it + * + * Note: this is largely copied from: + * board/seeed/linkit_smart_7688/board.c + * Copyright (C) 2018 Stefan Roese sr@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@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__
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@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@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@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@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@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@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@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "jedec,spi-nor"; + spi-max-frequency = <25000000>; + reg = <0>; + }; +};
+ð { + 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@mclink.it
- Note: this is largely copied from:
- * board/seeed/linkit_smart_7688/board.c
- * Copyright (C) 2018 Stefan Roese sr@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@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@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@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@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@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@10110000 (eth0) using random MAC address - 26:9f:0f:24:ae:39 eth0: eth@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@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@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@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@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@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@10110000 (eth0) using random MAC address - 26:9f:0f:24:ae:39 eth0: eth@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@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@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@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@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@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@10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93 eth0: eth@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@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@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@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@10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93 eth0: eth@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
On Wed, Feb 12, 2020 at 10:23 AM Mauro Condarelli mc5686@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
participants (4)
-
Daniel Schwierzeck -
Mauro Condarelli -
Stefan -
Weijie Gao