* How to debug HW startup? @ 2020-01-09 17:28 Mauro Condarelli 2020-01-10 6:31 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-09 17:28 UTC (permalink / raw) To: u-boot I managed to brick my target. Situation: I have a board with a paleolithic (1.1.3) version of u-boot. I had been testing by loading in ram from USB: usb reset; fatload usb 0 80010000 u-boot.bin; go 80010000 and everything was ok. I changed a few settings (both defconfigs are attached below) and tried "the real thing" Unfortunately reflashing the actual boot produced a brick. It does not utter a single byte. I will have to reflash the original using an external apparatus (which I don't have here, so I'll have to take target to another location, probably tomorrow morning), but question is: how do I debug such a situation? What could I have done so wrong? As You can see I changed only a few settings: --- configs/vocore_vocore2-ram_defconfig 2020-01-09 16:11:12.568096050 +0100 +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 +0100 @@ -1,9 +1,12 @@ CONFIG_MIPS=y -CONFIG_SYS_TEXT_BASE=0x80010000 +CONFIG_SYS_TEXT_BASE=0x9c000000 CONFIG_ENV_SIZE=0x00001000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y +CONFIG_BOOT_ROM=y +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y ... in a way that's very similar to boards based on the same SoC (linkit-smart-7688 and gardena-smart-gateway-mt7688). In the ancient u-boot I had to remove a header from the RAM version, but this was not needed with current u-boot. Did I forget some step? Any hint welcome Thanks in advance Mauro -------------- next part -------------- CONFIG_MIPS=y CONFIG_SYS_TEXT_BASE=0x9c000000 CONFIG_ENV_SIZE=0x00001000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y CONFIG_BOOT_ROM=y CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=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_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_USE_BOOTARGS=y CONFIG_LOGLEVEL=8 CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_AUTOBOOT is not set # 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_XIMG is not set CONFIG_CMD_MEMINFO=y CONFIG_CMD_GPIO=y CONFIG_RANDOM_UUID=y # CONFIG_CMD_LOADB is not set # 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_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)" # CONFIG_ISO_PARTITION is not set 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_NET is not set # CONFIG_DM_DEVICE_REMOVE is not set # CONFIG_INPUT is not set 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_MTD=y # CONFIG_DM_ETH is not set # CONFIG_RAM_ROCKCHIP_DEBUG is not set CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=3 CONFIG_SPI=y CONFIG_MT7621_SPI=y CONFIG_SYSRESET_SYSCON=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_LZMA=y CONFIG_LZO=y -------------- next part -------------- CONFIG_MIPS=y CONFIG_SYS_TEXT_BASE=0x80010000 CONFIG_ENV_SIZE=0x00001000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=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_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_USE_BOOTARGS=y CONFIG_LOGLEVEL=8 CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_AUTOBOOT is not set # 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_XIMG is not set CONFIG_CMD_MEMINFO=y CONFIG_CMD_GPIO=y CONFIG_RANDOM_UUID=y # CONFIG_CMD_LOADB is not set # 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_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)" # CONFIG_ISO_PARTITION is not set 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_NET is not set # CONFIG_DM_DEVICE_REMOVE is not set # CONFIG_INPUT is not set 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_MTD=y # CONFIG_DM_ETH is not set # CONFIG_RAM_ROCKCHIP_DEBUG is not set CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=3 CONFIG_SPI=y CONFIG_MT7621_SPI=y CONFIG_SYSRESET_SYSCON=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_LZMA=y CONFIG_LZO=y ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-09 17:28 How to debug HW startup? Mauro Condarelli @ 2020-01-10 6:31 ` Stefan Roese 2020-01-10 9:06 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-10 6:31 UTC (permalink / raw) To: u-boot Hi Mauro, On 09.01.20 18:28, Mauro Condarelli wrote: > I managed to brick my target. > > Situation: > I have a board with a paleolithic (1.1.3) version of u-boot. > I had been testing by loading in ram from USB: > usb reset; fatload usb 0 80010000 u-boot.bin; go 80010000 > and everything was ok. > I changed a few settings (both defconfigs are attached below) > and tried "the real thing" > Unfortunately reflashing the actual boot produced a brick. > It does not utter a single byte. Ugh. Too bad. > I will have to reflash the original using an external apparatus > (which I don't have here, so I'll have to take target to another > location, probably tomorrow morning), but question is: > how do I debug such a situation? To debug very early problems, I suggest to use the DEBUG_UART interface in U-Boot. I also used it quite a lot before - also on this platform. Please see: include/debug_uart.h: debug_uart_init(); printhex8(0x01); ... When using UART2 on the MT7628 please make sure to configure the pin mux before using the debug uart. Otherwise nothing will get printed. BTW: This might also be a problem on your board, if you use UART2 and the muxing is not done no output will occur. > What could I have done so wrong? > > As You can see I changed only a few settings: > > --- configs/vocore_vocore2-ram_defconfig 2020-01-09 > 16:11:12.568096050 +0100 > +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 +0100 > @@ -1,9 +1,12 @@ > CONFIG_MIPS=y > -CONFIG_SYS_TEXT_BASE=0x80010000 > +CONFIG_SYS_TEXT_BASE=0x9c000000 > CONFIG_ENV_SIZE=0x00001000 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_ARCH_MTMIPS=y > CONFIG_BOARD_VOCORE2=y > +CONFIG_BOOT_ROM=y > +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y > +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y > CONFIG_MIPS_BOOT_FDT=y > CONFIG_ENV_VARS_UBOOT_CONFIG=y > CONFIG_SYS_BOOT_GET_CMDLINE=y > ... in a way that's very similar to boards based on the same SoC > (linkit-smart-7688 and gardena-smart-gateway-mt7688). > > In the ancient u-boot I had to remove a header from the RAM > version, but this was not needed with current u-boot. > > Did I forget some step? Did you never program U-Boot into SPI NOR before on your VoCore2? Which binary did you program? How do the fist line look like? Here my output: $ hexdump -n 256 u-boot.bin 0000000 013f 1000 4800 4080 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 * 0000100 Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-10 6:31 ` Stefan Roese @ 2020-01-10 9:06 ` Mauro Condarelli 2020-01-10 13:33 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-10 9:06 UTC (permalink / raw) To: u-boot On 1/10/20 7:31 AM, Stefan Roese wrote: > Hi Mauro, > > On 09.01.20 18:28, Mauro Condarelli wrote: >> I managed to brick my target. >> >> Situation: >> I have a board with a paleolithic (1.1.3) version of u-boot. >> I had been testing by loading in ram from USB: >> usb reset; fatload usb 0 80010000 u-boot.bin; go 80010000 >> and everything was ok. >> I changed a few settings (both defconfigs are attached below) >> and tried "the real thing" >> Unfortunately reflashing the actual boot produced a brick. >> It does not utter a single byte. > > Ugh. Too bad. I know... :( >> I will have to reflash the original using an external apparatus >> (which I don't have here, so I'll have to take target to another >> location, probably tomorrow morning), but question is: >> how do I debug such a situation? > > To debug very early problems, I suggest to use the DEBUG_UART interface > in U-Boot. I also used it quite a lot before - also on this platform. > > Please see: > > include/debug_uart.h: > > debug_uart_init(); > printhex8(0x01); > ... > > When using UART2 on the MT7628 please make sure to configure the pin > mux before using the debug uart. Otherwise nothing will get printed. I do *not* do anything explicitly in my code, but I have stanzas in .dts Is that supposed to be enough? (I attach my current .dts as I'm sorry to say I don't really fully grok .dts and I'm merely copying stanzas around). I have Your code in board/vocore/vocore2/board.c (attached), shouldn't that be enough? > BTW: This might also be a problem on your board, if you use UART2 and > the muxing is not done no output will occur. I understand (see above). >> What could I have done so wrong? >> >> As You can see I changed only a few settings: >> >> --- configs/vocore_vocore2-ram_defconfig 2020-01-09 >> 16:11:12.568096050 +0100 >> +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 >> +0100 >> @@ -1,9 +1,12 @@ >> CONFIG_MIPS=y >> -CONFIG_SYS_TEXT_BASE=0x80010000 >> +CONFIG_SYS_TEXT_BASE=0x9c000000 >> CONFIG_ENV_SIZE=0x00001000 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ARCH_MTMIPS=y >> CONFIG_BOARD_VOCORE2=y >> +CONFIG_BOOT_ROM=y >> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y >> +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y >> CONFIG_MIPS_BOOT_FDT=y >> CONFIG_ENV_VARS_UBOOT_CONFIG=y >> CONFIG_SYS_BOOT_GET_CMDLINE=y >> ... in a way that's very similar to boards based on the same SoC >> (linkit-smart-7688 and gardena-smart-gateway-mt7688). >> >> In the ancient u-boot I had to remove a header from the RAM >> version, but this was not needed with current u-boot. >> >> Did I forget some step? > > Did you never program U-Boot into SPI NOR before on your VoCore2? Yes. Up to now I've been using the RAM-version and loaded it from my old (paleolithic 1.1.3) vendor-provided u-boot. Note: I have modified and reflashed *that* u-boot several times, so I was kind of confident I could do without much problem. Of course it's fully possible some initialization done by old code is missing in the new one. > Which binary did you program? I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin"; this is exactly the same file I used for my RAM-based tests (after switching _defconfig and recompiling, of course). > How do the fist line look like? Here my output: > > $ hexdump -n 256 u-boot.bin > 0000000 013f 1000 4800 4080 0000 0000 0000 0000 > 0000010 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000100 Mine is quite similar: $ hexdump -n 256 u-boot.bin 0000000 013f 1000 4800 4080 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0000 * 0000100 I'm about to go where there's a nailbed to reflash SPI NOR "from outside"; I plan to read back what's on flash before putting back the "old" u-boot to see if something went wrong while flashing (but I doubt it). Problem is how to proceed. Old code did a lot of hard-coded initialization (non-DT-based) which I don't (explicitly) do here (including a long RAM calibration I didn't even try to understand). I will bring back a certain number of working modules, so I will have a certain number of "tries" before I need to go back for hard reflashing; I should try to minimize commuting ;) > Thanks, > Stefan Many Thanks Mauro -------------- next part -------------- // SPDX-License-Identifier: GPL-2.0 #include <dt-bindings/clock/mt7628-clk.h> #include <dt-bindings/reset/mt7628-reset.h> / { #address-cells = <1>; #size-cells = <1>; compatible = "ralink,mt7628a-soc"; cpus { #address-cells = <1>; #size-cells = <0>; cpu at 0 { compatible = "mti,mips24KEc"; device_type = "cpu"; reg = <0>; }; }; cpuintc: interrupt-controller { #address-cells = <0>; #interrupt-cells = <1>; interrupt-controller; compatible = "mti,cpu-interrupt-controller"; }; clk48m: clk48m at 0 { compatible = "fixed-clock"; clock-frequency = <48000000>; #clock-cells = <0>; }; palmbus at 10000000 { compatible = "palmbus", "simple-bus"; reg = <0x10000000 0x200000>; ranges = <0x0 0x10000000 0x1FFFFF>; #address-cells = <1>; #size-cells = <1>; sysc: system-controller at 0 { compatible = "ralink,mt7620a-sysc", "syscon"; reg = <0x0 0x100>; }; syscon-reboot { compatible = "syscon-reboot"; regmap = <&sysc>; offset = <0x34>; mask = <0x1>; }; clkctrl: clkctrl at 0x2c { reg = <0x2c 0x8>, <0x10 0x4>; reg-names = "syscfg0", "clkcfg"; compatible = "mediatek,mt7628-clk"; #clock-cells = <1>; u-boot,dm-pre-reloc; }; clkgate: clkgate at 0x30 { reg = <0x30 0x4>; compatible = "mediatek,mtmips-clk-gate"; #clock-cells = <1>; }; rstctrl: rstctrl at 0x34 { reg = <0x34 0x4>; compatible = "mediatek,mtmips-reset"; #reset-cells = <1>; }; pinctrl: pinctrl at 60 { compatible = "mediatek,mt7628-pinctrl"; reg = <0x3c 0x2c>, <0x1300 0x100>; reg-names = "gpiomode", "padconf"; pinctrl-names = "default"; pinctrl-0 = <&state_default>; state_default: pin_state { }; spi_single_pins: spi_single_pins { groups = "spi"; function = "spi"; }; spi_dual_pins: spi_dual_pins { spi_master_pins { groups = "spi"; function = "spi"; }; spi_cs1_pin { groups = "spi cs1"; function = "spi cs1"; }; }; uart0_pins: uart0_pins { groups = "uart0"; function = "uart0"; }; uart1_pins: uart1_pins { groups = "uart1"; function = "uart1"; }; uart2_pins: uart2_pins { groups = "uart2"; function = "uart2"; }; i2c_pins: i2c_pins { groups = "i2c"; function = "i2c"; }; ephy_iot_mode: ephy_iot_mode { ephy4_1_dis { groups = "ephy4_1_pad"; function = "digital"; }; ephy0_en { groups = "ephy0"; function = "enable"; }; }; ephy_router_mode: ephy_router_mode { ephy4_1_en { groups = "ephy4_1_pad"; function = "analog"; }; ephy0_en { groups = "ephy0"; function = "enable"; }; }; sd_iot_mode: sd_iot_mode { ephy4_1_dis { groups = "ephy4_1_pad"; function = "digital"; }; sdxc_en { groups = "sdmode"; function = "sdxc"; }; sdxc_iot_mode { groups = "sd router"; function = "iot"; }; sd_clk_pad { pins = "sd_clk"; drive-strength-4g = <8>; }; }; sd_router_mode: sd_router_mode { sdxc_router_mode { groups = "sd router"; function = "router"; }; sdxc_map_pins { groups = "gpio0", "i2s", "sdmode", \ "i2c", "uart1"; function = "gpio"; }; sd_clk_pad { pins = "gpio0"; drive-strength-28 = <8>; }; }; emmc_iot_8bit_mode: emmc_iot_8bit_mode { ephy4_1_dis { groups = "ephy4_1_pad"; function = "digital"; }; emmc_en { groups = "sdmode"; function = "sdxc"; }; emmc_iot_mode { groups = "sd router"; function = "iot"; }; emmc_d4_d5 { groups = "uart2"; function = "sdxc d5 d4"; }; emmc_d6 { groups = "pwm1"; function = "sdxc d6"; }; emmc_d7 { groups = "pwm0"; function = "sdxc d7"; }; sd_clk_pad { pins = "sd_clk"; drive-strength-4g = <8>; }; }; }; watchdog: watchdog at 100 { compatible = "ralink,mt7628a-wdt", "mediatek,mt7621-wdt"; reg = <0x100 0x30>; resets = <&rstctrl MT7628_TIMER_RST>; reset-names = "wdt"; interrupt-parent = <&intc>; interrupts = <24>; }; intc: interrupt-controller at 200 { compatible = "ralink,rt2880-intc"; reg = <0x200 0x100>; interrupt-controller; #interrupt-cells = <1>; resets = <&rstctrl MT7628_INT_RST>; reset-names = "intc"; interrupt-parent = <&cpuintc>; interrupts = <2>; ralink,intc-registers = <0x9c 0xa0 0x6c 0xa4 0x80 0x78>; }; memory-controller at 300 { compatible = "ralink,mt7620a-memc"; reg = <0x300 0x100>; }; gpio at 600 { #address-cells = <1>; #size-cells = <0>; compatible = "mtk,mt7628-gpio", "mtk,mt7621-gpio"; reg = <0x600 0x100>; resets = <&rstctrl MT7628_PIO_RST>; reset-names = "pio"; interrupt-parent = <&intc>; interrupts = <6>; gpio0: bank at 0 { reg = <0>; compatible = "mtk,mt7621-gpio-bank"; gpio-controller; #gpio-cells = <2>; }; gpio1: bank at 1 { reg = <1>; compatible = "mtk,mt7621-gpio-bank"; gpio-controller; #gpio-cells = <2>; }; gpio2: bank at 2 { reg = <2>; compatible = "mtk,mt7621-gpio-bank"; gpio-controller; #gpio-cells = <2>; }; }; spi0: spi at b00 { compatible = "ralink,mt7621-spi"; reg = <0xb00 0x40>; resets = <&rstctrl MT7628_SPI_RST>; reset-names = "spi"; #address-cells = <1>; #size-cells = <0>; clocks = <&clkctrl CLK_SPI>; }; uart0: uartlite at c00 { compatible = "mediatek,hsuart", "ns16550a"; reg = <0xc00 0x100>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; clocks = <&clkctrl CLK_UART0>; resets = <&rstctrl MT7628_UART0_RST>; reset-names = "uart0"; interrupt-parent = <&intc>; interrupts = <20>; reg-shift = <2>; }; uart1: uart1 at d00 { compatible = "mediatek,hsuart", "ns16550a"; reg = <0xd00 0x100>; pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>; clocks = <&clkctrl CLK_UART1>; resets = <&rstctrl MT7628_UART1_RST>; reset-names = "uart1"; interrupt-parent = <&intc>; interrupts = <21>; reg-shift = <2>; }; uart2: uart2 at e00 { compatible = "mediatek,hsuart", "ns16550a"; reg = <0xe00 0x100>; pinctrl-names = "default"; pinctrl-0 = <&uart2_pins>; clocks = <&clkctrl CLK_UART2>; resets = <&rstctrl MT7628_UART2_RST>; reset-names = "uart2"; interrupt-parent = <&intc>; interrupts = <22>; reg-shift = <2>; }; }; eth: eth at 10110000 { compatible = "mediatek,mt7628-eth"; reg = <0x10100000 0x10000 0x10110000 0x8000>; resets = <&rstctrl MT7628_EPHY_RST>; reset-names = "ephy"; syscon = <&sysc>; }; usb_phy: usb-phy at 10120000 { compatible = "mediatek,mt7628-usbphy"; reg = <0x10120000 0x1000>; #phy-cells = <0>; ralink,sysctl = <&sysc>; resets = <&rstctrl MT7628_UPHY_RST>; reset-names = "phy"; clocks = <&clkctrl CLK_UPHY>; clock-names = "cg"; }; ehci at 101c0000 { compatible = "generic-ehci"; reg = <0x101c0000 0x1000>; phys = <&usb_phy>; phy-names = "usb"; interrupt-parent = <&intc>; interrupts = <18>; }; mmc: mmc at 10130000 { compatible = "mediatek,mt7620-mmc"; reg = <0x10130000 0x4000>; builtin-cd = <1>; r_smpl = <1>; interrupt-parent = <&intc>; interrupts = <14>; clocks = <&clk48m>, <&clk48m>; clock-names = "source", "hclk"; pinctrl-names = "default", "state_uhs"; pinctrl-0 = <&sd_iot_mode>; pinctrl-1 = <&sd_iot_mode>; vmmc-supply = <&clk48m>; vqmmc-supply = <&clk48m>; resets = <&rstctrl MT7628_SDXC_RST>; status = "disabled"; }; }; -------------- next part -------------- A non-text attachment was scrubbed... Name: vocore_vocore2.dts Type: audio/vnd.dts Size: 880 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200110/a62ebe3c/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: board.c Type: text/x-csrc Size: 784 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200110/a62ebe3c/attachment.c> ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-10 9:06 ` Mauro Condarelli @ 2020-01-10 13:33 ` Stefan Roese 2020-01-11 19:00 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-10 13:33 UTC (permalink / raw) To: u-boot Hi Mauro, (added Weijie to Cc) On 10.01.20 10:06, Mauro Condarelli wrote: > > > On 1/10/20 7:31 AM, Stefan Roese wrote: >> Hi Mauro, >> >> On 09.01.20 18:28, Mauro Condarelli wrote: >>> I managed to brick my target. >>> >>> Situation: >>> I have a board with a paleolithic (1.1.3) version of u-boot. >>> I had been testing by loading in ram from USB: >>> usb reset; fatload usb 0 80010000 u-boot.bin; go 80010000 >>> and everything was ok. >>> I changed a few settings (both defconfigs are attached below) >>> and tried "the real thing" >>> Unfortunately reflashing the actual boot produced a brick. >>> It does not utter a single byte. >> >> Ugh. Too bad. > I know... :( > >>> I will have to reflash the original using an external apparatus >>> (which I don't have here, so I'll have to take target to another >>> location, probably tomorrow morning), but question is: >>> how do I debug such a situation? >> >> To debug very early problems, I suggest to use the DEBUG_UART interface >> in U-Boot. I also used it quite a lot before - also on this platform. >> >> Please see: >> >> include/debug_uart.h: >> >> debug_uart_init(); >> printhex8(0x01); >> ... >> >> When using UART2 on the MT7628 please make sure to configure the pin >> mux before using the debug uart. Otherwise nothing will get printed. > I do *not* do anything explicitly in my code, but I have stanzas in .dts > Is that supposed to be enough? (I attach my current .dts as I'm sorry to > say I don't really fully grok .dts and I'm merely copying stanzas around). > > I have Your code in board/vocore/vocore2/board.c (attached), shouldn't > that be enough? Yes, this should be enough when using UART2 IIRC. BTW: I just noticed that the VoCore uses the MT7628 and the LinkIt and the GARDENA boards both use the MT7688. I don't remember the differences but I don't think this should be a problem. > >> BTW: This might also be a problem on your board, if you use UART2 and >> the muxing is not done no output will occur. > I understand (see above). > >>> What could I have done so wrong? >>> >>> As You can see I changed only a few settings: >>> >>> --- configs/vocore_vocore2-ram_defconfig 2020-01-09 >>> 16:11:12.568096050 +0100 >>> +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 >>> +0100 >>> @@ -1,9 +1,12 @@ >>> CONFIG_MIPS=y >>> -CONFIG_SYS_TEXT_BASE=0x80010000 >>> +CONFIG_SYS_TEXT_BASE=0x9c000000 >>> CONFIG_ENV_SIZE=0x00001000 >>> CONFIG_NR_DRAM_BANKS=1 >>> CONFIG_ARCH_MTMIPS=y >>> CONFIG_BOARD_VOCORE2=y >>> +CONFIG_BOOT_ROM=y >>> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y >>> +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y >>> CONFIG_MIPS_BOOT_FDT=y >>> CONFIG_ENV_VARS_UBOOT_CONFIG=y >>> CONFIG_SYS_BOOT_GET_CMDLINE=y >>> ... in a way that's very similar to boards based on the same SoC >>> (linkit-smart-7688 and gardena-smart-gateway-mt7688). >>> >>> In the ancient u-boot I had to remove a header from the RAM >>> version, but this was not needed with current u-boot. >>> >>> Did I forget some step? >> >> Did you never program U-Boot into SPI NOR before on your VoCore2? > Yes. Autsch. > Up to now I've been using the RAM-version and loaded it from my old > (paleolithic 1.1.3) vendor-provided u-boot. > Note: I have modified and reflashed *that* u-boot several times, so I > was kind of confident I could do without much problem. > Of course it's fully possible some initialization done by old code is > missing in the new one. > >> Which binary did you program? > I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin"; Yes, both images are identical. > this is exactly the same file I used for my RAM-based tests > (after switching _defconfig and recompiling, of course). Do you have a list of differences of the LinkIt MT7688 and the VoCore2 board? Like DDR2 setup, UART etc? >> How do the fist line look like? Here my output: >> >> $ hexdump -n 256 u-boot.bin >> 0000000 013f 1000 4800 4080 0000 0000 0000 0000 >> 0000010 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 0000100 > Mine is quite similar: > $ hexdump -n 256 u-boot.bin > 0000000 013f 1000 4800 4080 0000 0000 0000 0000 > 0000010 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000100 Ok, this is not a problem. The image is the "correct" one. > I'm about to go where there's a nailbed to reflash SPI NOR > "from outside"; I plan to read back what's on flash before > putting back the "old" u-boot to see if something went wrong > while flashing (but I doubt it). > > Problem is how to proceed. > Old code did a lot of hard-coded initialization (non-DT-based) > which I don't (explicitly) do here (including a long RAM calibration > I didn't even try to understand). The RAM code is nearly identical. The current mainline code is "cloned" from the MediaTek (paleolithic) version. So I don't suspect a problem here. This will change btw with the new code from Weijie. He re-wrote the early init code including the DDR/DDR2 code and its calibration. I already tested this code on the Linkit board and it worked there without any issues. Still the current DDR2 code "should" work on your board as well. > I will bring back a certain number of working modules, so I will > have a certain number of "tries" before I need to go back for > hard reflashing; I should try to minimize commuting ;) Right. Again, I suggest to use the DEBUG UART for early debugging. You might also want to give the new version / patches from Weijie a try. He added SPL support and a "cleaner" init code for this SoC. Perhaps this helps as well. Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-10 13:33 ` Stefan Roese @ 2020-01-11 19:00 ` Mauro Condarelli 2020-01-11 20:42 ` Sean Anderson 2020-01-13 6:53 ` Stefan Roese 0 siblings, 2 replies; 30+ messages in thread From: Mauro Condarelli @ 2020-01-11 19:00 UTC (permalink / raw) To: u-boot Hi Stefan, I managed to find ONE of the reasons why my ROM build didn't run: I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. I wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below). On 1/10/20 2:33 PM, Stefan Roese wrote: > Hi Mauro, > > (added Weijie to Cc) > > On 10.01.20 10:06, Mauro Condarelli wrote: >> >> >> On 1/10/20 7:31 AM, Stefan Roese wrote: >>> Hi Mauro, >>> >>> On 09.01.20 18:28, Mauro Condarelli wrote: >>>> I managed to brick my target. >>>> >>>> Situation: >>>> I have a board with a paleolithic (1.1.3) version of u-boot. >>>> I had been testing by loading in ram from USB: >>>> usb reset; fatload usb 0 80010000 u-boot.bin; go 80010000 >>>> and everything was ok. >>>> I changed a few settings (both defconfigs are attached below) >>>> and tried "the real thing" >>>> Unfortunately reflashing the actual boot produced a brick. >>>> It does not utter a single byte. >>> >>> Ugh. Too bad. >> I know... :( >> >>>> I will have to reflash the original using an external apparatus >>>> (which I don't have here, so I'll have to take target to another >>>> location, probably tomorrow morning), but question is: >>>> how do I debug such a situation? >>> >>> To debug very early problems, I suggest to use the DEBUG_UART interface >>> in U-Boot. I also used it quite a lot before - also on this platform. >>> >>> Please see: >>> >>> include/debug_uart.h: >>> >>> debug_uart_init(); >>> printhex8(0x01); >>> ... Could You share a Linkit _defconfig with early serial debug enabled? I'm decidedly missing something as, even enabling CONFIG_DEBUG_UART=y CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y I still have plenty of errors: /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: arch/mips/cpu/start.o: in function `wr_done': (.text+0x650): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: (.text+0x654): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: board/vocore/vocore2/built-in.o: in function `board_early_init_f': (.text.board_early_init_f+0x10): undefined reference to `printhex8' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `putc': (.text.putc+0x18): undefined reference to `printch' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `puts': (.text.puts+0x2c): undefined reference to `printch' >>> >>> When using UART2 on the MT7628 please make sure to configure the pin >>> mux before using the debug uart. Otherwise nothing will get printed. >> I do *not* do anything explicitly in my code, but I have stanzas in .dts >> Is that supposed to be enough? (I attach my current .dts as I'm sorry to >> say I don't really fully grok .dts and I'm merely copying stanzas >> around). >> >> I have Your code in board/vocore/vocore2/board.c (attached), shouldn't >> that be enough? > > Yes, this should be enough when using UART2 IIRC. > > BTW: I just noticed that the VoCore uses the MT7628 and the LinkIt and > the GARDENA boards both use the MT7688. I don't remember the differences > but I don't think this should be a problem. AFAIK differences between MT7628 and MT7688 are restricted to WiFi radio section (MT7628 is 2r2t while MT7688 is 1r1t); any addendum to this I would like to know. >>> BTW: This might also be a problem on your board, if you use UART2 and >>> the muxing is not done no output will occur. >> I understand (see above). >> >>>> What could I have done so wrong? >>>> >>>> As You can see I changed only a few settings: >>>> >>>> --- configs/vocore_vocore2-ram_defconfig 2020-01-09 >>>> 16:11:12.568096050 +0100 >>>> +++ configs/vocore_vocore2_defconfig 2020-01-09 16:07:10.528267378 >>>> +0100 >>>> @@ -1,9 +1,12 @@ >>>> CONFIG_MIPS=y >>>> -CONFIG_SYS_TEXT_BASE=0x80010000 >>>> +CONFIG_SYS_TEXT_BASE=0x9c000000 >>>> CONFIG_ENV_SIZE=0x00001000 >>>> CONFIG_NR_DRAM_BANKS=1 >>>> CONFIG_ARCH_MTMIPS=y >>>> CONFIG_BOARD_VOCORE2=y >>>> +CONFIG_BOOT_ROM=y >>>> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y >>>> +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y >>>> CONFIG_MIPS_BOOT_FDT=y >>>> CONFIG_ENV_VARS_UBOOT_CONFIG=y >>>> CONFIG_SYS_BOOT_GET_CMDLINE=y >>>> ... in a way that's very similar to boards based on the same SoC >>>> (linkit-smart-7688 and gardena-smart-gateway-mt7688). >>>> >>>> In the ancient u-boot I had to remove a header from the RAM >>>> version, but this was not needed with current u-boot. >>>> >>>> Did I forget some step? >>> >>> Did you never program U-Boot into SPI NOR before on your VoCore2? >> Yes. > > Autsch. > >> Up to now I've been using the RAM-version and loaded it from my old >> (paleolithic 1.1.3) vendor-provided u-boot. >> Note: I have modified and reflashed *that* u-boot several times, so I >> was kind of confident I could do without much problem. >> Of course it's fully possible some initialization done by old code is >> missing in the new one. >> >>> Which binary did you program? >> I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin"; > > Yes, both images are identical. > >> this is exactly the same file I used for my RAM-based tests >> (after switching _defconfig and recompiling, of course). > > Do you have a list of differences of the LinkIt MT7688 and the VoCore2 > board? Like DDR2 setup, UART etc? > >>> How do the fist line look like? Here my output: >>> >>> $ hexdump -n 256 u-boot.bin >>> 0000000 013f 1000 4800 4080 0000 0000 0000 0000 >>> 0000010 0000 0000 0000 0000 0000 0000 0000 0000 >>> * >>> 0000100 >> Mine is quite similar: >> $ hexdump -n 256 u-boot.bin >> 0000000 013f 1000 4800 4080 0000 0000 0000 0000 >> 0000010 0000 0000 0000 0000 0000 0000 0000 0000 >> * >> 0000100 > > Ok, this is not a problem. The image is the "correct" one. > >> I'm about to go where there's a nailbed to reflash SPI NOR >> "from outside"; I plan to read back what's on flash before >> putting back the "old" u-boot to see if something went wrong >> while flashing (but I doubt it). >> >> Problem is how to proceed. >> Old code did a lot of hard-coded initialization (non-DT-based) >> which I don't (explicitly) do here (including a long RAM calibration >> I didn't even try to understand). > > The RAM code is nearly identical. The current mainline code is "cloned" > from the MediaTek (paleolithic) version. So I don't suspect a problem > here. This will change btw with the new code from Weijie. He re-wrote > the early init code including the DDR/DDR2 code and its calibration. > I already tested this code on the Linkit board and it worked there > without any issues. > > Still the current DDR2 code "should" work on your board as well. > >> I will bring back a certain number of working modules, so I will >> have a certain number of "tries" before I need to go back for >> hard reflashing; I should try to minimize commuting ;) > > Right. Again, I suggest to use the DEBUG UART for early debugging. I'm having a few problems in that department... > You might also want to give the new version / patches from Weijie > a try. He added SPL support and a "cleaner" init code for this SoC. I'm interested in giving it a spin (and help debugging on another HW, if needed), but I would like to have a solid base from where to move, changing too many things at once is rarely a good strategy ;) > Perhaps this helps as well. > > Thanks, > Stefan > Thanks Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-11 19:00 ` Mauro Condarelli @ 2020-01-11 20:42 ` Sean Anderson 2020-01-11 21:38 ` Mauro Condarelli 2020-01-13 6:53 ` Stefan Roese 1 sibling, 1 reply; 30+ messages in thread From: Sean Anderson @ 2020-01-11 20:42 UTC (permalink / raw) To: u-boot > Could You share a Linkit _defconfig with early serial debug enabled? > I'm decidedly missing something as, even enabling > > CONFIG_DEBUG_UART=y > CONFIG_DEBUG_UART_BASE=0x10000e00 > CONFIG_DEBUG_UART_CLOCK=20 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_DEBUG_UART_ANNOUNCE=y > > I still have plenty of errors: > > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > arch/mips/cpu/start.o: in function `wr_done': > (.text+0x650): undefined reference to `debug_uart_init' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > (.text+0x654): undefined reference to `debug_uart_init' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > board/vocore/vocore2/built-in.o: in function `board_early_init_f': > (.text.board_early_init_f+0x10): undefined reference to `printhex8' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > common/built-in.o: in function `putc': > (.text.putc+0x18): undefined reference to `printch' > /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: > common/built-in.o: in function `puts': > (.text.puts+0x2c): undefined reference to `printch' > You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-11 20:42 ` Sean Anderson @ 2020-01-11 21:38 ` Mauro Condarelli 2020-01-11 23:58 ` Sean Anderson 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-11 21:38 UTC (permalink / raw) To: u-boot Thanks Joel, unfortunately I already have that defined, even if I forgot to copy it. I attach my full .config for reference as I have no idea what I'm still missing. On 1/11/20 9:42 PM, Sean Anderson wrote: >> Could You share a Linkit _defconfig with early serial debug enabled? >> I'm decidedly missing something as, even enabling >> >> CONFIG_DEBUG_UART=y >> CONFIG_DEBUG_UART_BASE=0x10000e00 >> CONFIG_DEBUG_UART_CLOCK=20 >> CONFIG_DEBUG_UART_SHIFT=2 >> CONFIG_DEBUG_UART_ANNOUNCE=y >> >> I still have plenty of errors: >> >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> arch/mips/cpu/start.o: in function `wr_done': >> (.text+0x650): undefined reference to `debug_uart_init' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> (.text+0x654): undefined reference to `debug_uart_init' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> board/vocore/vocore2/built-in.o: in function `board_early_init_f': >> (.text.board_early_init_f+0x10): undefined reference to `printhex8' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> common/built-in.o: in function `putc': >> (.text.putc+0x18): undefined reference to `printch' >> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: >> common/built-in.o: in function `puts': >> (.text.puts+0x2c): undefined reference to `printch' >> > You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. As said I have it, but I'm not sure about the other parameters. Maybe a better choice would be CONFIG_DEBUG_UART_MTK. Having a "known good" configuration would help a lot. Regards Mauro -------------- next part -------------- # # Automatically generated file; DO NOT EDIT. # U-Boot 2020.01 Configuration # CONFIG_HAVE_ARCH_IOREMAP=y # CONFIG_ARC is not set # CONFIG_ARM is not set # CONFIG_M68K is not set # CONFIG_MICROBLAZE is not set CONFIG_MIPS=y # CONFIG_NDS32 is not set # CONFIG_NIOS2 is not set # CONFIG_PPC is not set # CONFIG_RISCV is not set # CONFIG_SANDBOX is not set # CONFIG_SH is not set # CONFIG_X86 is not set # CONFIG_XTENSA is not set CONFIG_SYS_ARCH="mips" CONFIG_SYS_CPU="mips32" CONFIG_SYS_SOC="mt7628" CONFIG_SYS_VENDOR="vocore" CONFIG_SYS_BOARD="vocore2" CONFIG_SYS_CONFIG_NAME="vocore2" CONFIG_SYS_TEXT_BASE=0x80010000 CONFIG_SYS_MALLOC_F_LEN=0x1000 CONFIG_ENV_SIZE=0x00001000 CONFIG_DM_GPIO=y CONFIG_ERR_PTR_OFFSET=0x0 CONFIG_NR_DRAM_BANKS=1 CONFIG_BOOTSTAGE_STASH_ADDR=0 # CONFIG_DEBUG_UART_BOARD_INIT is not set CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_IDENT_STRING="" # # MIPS architecture # # CONFIG_TARGET_QEMU_MIPS is not set # CONFIG_TARGET_MALTA is not set # CONFIG_TARGET_VCT is not set # CONFIG_ARCH_ATH79 is not set # CONFIG_ARCH_MSCC is not set # CONFIG_ARCH_BMIPS is not set CONFIG_ARCH_MTMIPS=y # CONFIG_ARCH_JZ47XX is not set # CONFIG_MACH_PIC32 is not set # CONFIG_TARGET_BOSTON is not set # CONFIG_TARGET_XILFPGA is not set CONFIG_SYS_DCACHE_SIZE=0 CONFIG_SYS_DCACHE_LINE_SIZE=0 CONFIG_SYS_ICACHE_SIZE=0 CONFIG_SYS_ICACHE_LINE_SIZE=0 # # MediaTek MIPS platforms # CONFIG_SOC_MT7628=y # CONFIG_BOARD_GARDENA_SMART_GATEWAY_MT7688 is not set # CONFIG_BOARD_LINKIT_SMART_7688 is not set CONFIG_BOARD_VOCORE2=y CONFIG_BOOT_RAM=y # CONFIG_BOOT_ROM is not set CONFIG_SUPPORTS_BOOT_RAM=y CONFIG_SYS_LITTLE_ENDIAN=y # CONFIG_CPU_MIPS32_R1 is not set CONFIG_CPU_MIPS32_R2=y # # General setup # CONFIG_ROM_EXCEPTION_VECTORS=y CONFIG_MIPS_CACHE_INDEX_BASE=0x80000000 CONFIG_MIPS_RELOCATION_TABLE_SIZE=0x8000 # # OS boot interface # CONFIG_MIPS_BOOT_CMDLINE_LEGACY=y CONFIG_MIPS_BOOT_ENV_LEGACY=y CONFIG_MIPS_BOOT_FDT=y CONFIG_SUPPORTS_LITTLE_ENDIAN=y CONFIG_SUPPORTS_CPU_MIPS32_R1=y CONFIG_SUPPORTS_CPU_MIPS32_R2=y CONFIG_CPU_MIPS32=y CONFIG_MIPS_TUNE_24KC=y CONFIG_32BIT=y CONFIG_SYS_SCACHE_LINE_SIZE=0 CONFIG_SYS_CACHE_SIZE_AUTO=y CONFIG_MIPS_L1_CACHE_SHIFT_5=y CONFIG_MIPS_L1_CACHE_SHIFT=5 CONFIG_DEBUG_UART=y # CONFIG_AHCI is not set # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_DISTRO_DEFAULTS is not set CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y CONFIG_SYS_BOOT_GET_KBD=y CONFIG_SYS_MALLOC_F=y CONFIG_EXPERT=y CONFIG_SYS_MALLOC_CLEAR_ON_INIT=y # CONFIG_TOOLS_DEBUG is not set # CONFIG_PHYS_64BIT is not set CONFIG_BUILD_TARGET="" # CONFIG_SYS_CUSTOM_LDSCRIPT is not set # # Boot images # # CONFIG_ANDROID_BOOT_IMAGE is not set # CONFIG_FIT is not set CONFIG_LEGACY_IMAGE_FORMAT=y # CONFIG_OF_BOARD_SETUP is not set # CONFIG_OF_SYSTEM_SETUP is not set # CONFIG_OF_STDOUT_VIA_ALIAS is not set CONFIG_SYS_EXTRA_OPTIONS="" CONFIG_HAVE_SYS_TEXT_BASE=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set # # API # # CONFIG_API is not set # # Boot timing # # CONFIG_BOOTSTAGE is not set CONFIG_BOOTSTAGE_RECORD_COUNT=30 CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=5 CONFIG_TPL_BOOTSTAGE_RECORD_COUNT=5 CONFIG_BOOTSTAGE_STASH_SIZE=0x1000 # CONFIG_SHOW_BOOT_PROGRESS is not set # # Boot media # # CONFIG_NAND_BOOT is not set # CONFIG_ONENAND_BOOT is not set # CONFIG_QSPI_BOOT is not set # CONFIG_SATA_BOOT is not set # CONFIG_SD_BOOT is not set # CONFIG_SPI_BOOT is not set CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="" # CONFIG_USE_BOOTCOMMAND is not set # CONFIG_USE_PREBOOT is not set # # Console # # CONFIG_CONSOLE_RECORD is not set # CONFIG_DISABLE_CONSOLE is not set CONFIG_LOGLEVEL=8 CONFIG_SPL_LOGLEVEL=8 CONFIG_TPL_LOGLEVEL=8 # CONFIG_SILENT_CONSOLE is not set # CONFIG_PRE_CONSOLE_BUFFER is not set # CONFIG_CONSOLE_MUX is not set # CONFIG_SYS_CONSOLE_IS_IN_ENV is not set # CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE is not set # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SYS_CONSOLE_INFO_QUIET is not set # CONFIG_SYS_STDIO_DEREGISTER is not set # # Logging # # CONFIG_LOG is not set CONFIG_LOG_DEFAULT_LEVEL=6 # CONFIG_SUPPORT_RAW_INITRD is not set CONFIG_DEFAULT_FDT_FILE="" # CONFIG_MISC_INIT_R is not set CONFIG_VERSION_VARIABLE=y # CONFIG_BOARD_LATE_INIT is not set CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_BOUNCE_BUFFER is not set # CONFIG_BOARD_TYPES is not set # # Start-up hooks # CONFIG_ARCH_EARLY_INIT_R=y CONFIG_ARCH_MISC_INIT=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_LAST_STAGE_INIT=y # # Security support # CONFIG_HASH=y # # Update support # # CONFIG_ANDROID_AB is not set # # Blob list # # CONFIG_BLOBLIST is not set # # SPL / TPL # CONFIG_SPL_SYS_STACK_F_CHECK_BYTE=0xaa # CONFIG_SPL_SYS_REPORT_STACK_F_USAGE is not set # # PowerPC and LayerScape SPL Boot options # # # Command line interface # CONFIG_CMDLINE=y # CONFIG_HUSH_PARSER is not set CONFIG_CMDLINE_EDITING=y CONFIG_AUTO_COMPLETE=y CONFIG_SYS_LONGHELP=y CONFIG_SYS_PROMPT="=> " CONFIG_SYS_XTRACE="y" # # Autoboot options # # CONFIG_AUTOBOOT is not set # CONFIG_AUTOBOOT_KEYED is not set # CONFIG_AUTOBOOT_USE_MENUKEY is not set # # Commands # # # Info commands # CONFIG_CMD_BDI=y # CONFIG_CMD_CONFIG is not set CONFIG_CMD_CONSOLE=y # CONFIG_CMD_CPU is not set # CONFIG_CMD_LICENSE is not set # CONFIG_CMD_PMC is not set # # Boot commands # CONFIG_CMD_BOOTD=y CONFIG_CMD_BOOTM=y # CONFIG_CMD_BOOTZ is not set CONFIG_BOOTM_LINUX=y # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_OPENRTOS is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set # CONFIG_BOOTM_VXWORKS is not set # CONFIG_CMD_BOOTMENU is not set # CONFIG_CMD_DTIMG is not set CONFIG_CMD_ELF=y CONFIG_CMD_FDT=y CONFIG_CMD_GO=y CONFIG_CMD_RUN=y CONFIG_CMD_IMI=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_XIMG is not set # CONFIG_CMD_FITUPD is not set # CONFIG_CMD_THOR_DOWNLOAD is not set # CONFIG_CMD_ZBOOT is not set # # Environment commands # # CONFIG_CMD_ASKENV is not set CONFIG_CMD_EXPORTENV=y CONFIG_CMD_IMPORTENV=y CONFIG_CMD_EDITENV=y # CONFIG_CMD_GREPENV is not set CONFIG_CMD_SAVEENV=y # CONFIG_CMD_ERASEENV is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_CMD_NVEDIT_INFO is not set # # Memory commands # # CONFIG_CMD_BINOP is not set CONFIG_CMD_CRC32=y # CONFIG_CRC32_VERIFY is not set # CONFIG_CMD_EEPROM is not set # CONFIG_LOOPW is not set # CONFIG_CMD_MD5SUM is not set CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMORY=y # CONFIG_MX_CYCLIC is not set CONFIG_CMD_RANDOM=y # CONFIG_CMD_MEMTEST is not set # CONFIG_CMD_MX_CYCLIC is not set # CONFIG_CMD_SHA1SUM is not set # CONFIG_CMD_STRINGS is not set # # Compression commands # # CONFIG_CMD_LZMADEC is not set # CONFIG_CMD_UNZIP is not set # CONFIG_CMD_ZIP is not set # # Device access commands # # CONFIG_CMD_ARMFLASH is not set # CONFIG_CMD_ADC is not set # CONFIG_CMD_BCB is not set # CONFIG_CMD_BIND is not set # CONFIG_CMD_CLK is not set # CONFIG_CMD_DEMO is not set # CONFIG_CMD_DFU is not set CONFIG_CMD_DM=y # CONFIG_CMD_FDC is not set CONFIG_CMD_FLASH=y # CONFIG_CMD_FPGAD is not set # CONFIG_CMD_FUSE is not set CONFIG_CMD_GPIO=y # CONFIG_CMD_GPT is not set CONFIG_RANDOM_UUID=y # CONFIG_CMD_IDE is not set # CONFIG_CMD_IO is not set # CONFIG_CMD_IOTRACE is not set # CONFIG_CMD_I2C is not set # CONFIG_CMD_LOADB is not set # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y # CONFIG_CMD_MMC_RPMB is not set # CONFIG_CMD_MMC_SWRITE is not set CONFIG_CMD_MTD=y # CONFIG_CMD_ONENAND is not set # CONFIG_CMD_OSD is not set CONFIG_CMD_PART=y # CONFIG_CMD_PCI is not set CONFIG_CMD_PINMUX=y # CONFIG_CMD_POWEROFF is not set # CONFIG_CMD_READ is not set # CONFIG_CMD_SATA is not set # CONFIG_CMD_SAVES is not set # CONFIG_CMD_SCSI is not set # CONFIG_CMD_SDRAM is not set CONFIG_CMD_SF=y # CONFIG_CMD_SF_TEST is not set CONFIG_CMD_SPI=y CONFIG_DEFAULT_SPI_BUS=0 CONFIG_DEFAULT_SPI_MODE=0 # CONFIG_CMD_TSI148 is not set # CONFIG_CMD_UNIVERSE is not set CONFIG_CMD_USB=y # CONFIG_CMD_USB_SDP is not set # CONFIG_CMD_USB_MASS_STORAGE is not set CONFIG_CMD_WDT=y # # Shell scripting commands # CONFIG_CMD_ECHO=y CONFIG_CMD_ITEST=y CONFIG_CMD_SOURCE=y CONFIG_CMD_SETEXPR=y # # Android support commands # # # Misc commands # # CONFIG_CMD_BSP is not set # CONFIG_CMD_BKOPS_ENABLE is not set CONFIG_CMD_BLOCK_CACHE=y # CONFIG_CMD_CACHE is not set # CONFIG_CMD_CONITRACE is not set CONFIG_CMD_LED=y # CONFIG_CMD_DATE is not set # CONFIG_CMD_TIME is not set # CONFIG_CMD_GETTIME is not set CONFIG_CMD_MISC=y # CONFIG_MP is not set # CONFIG_CMD_TIMER is not set # CONFIG_CMD_SYSBOOT is not set # CONFIG_CMD_QFW is not set # CONFIG_CMD_TERMINAL is not set # CONFIG_CMD_UUID is not set # # TI specific command line interface # # CONFIG_CMD_DDR3 is not set # # Power commands # # # Security commands # # CONFIG_CMD_AES is not set # CONFIG_CMD_BLOB is not set # CONFIG_CMD_HASH is not set # # Firmware commands # # # Filesystem commands # # CONFIG_CMD_BTRFS is not set # CONFIG_CMD_EXT2 is not set # CONFIG_CMD_EXT4 is not set CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y # CONFIG_CMD_FS_UUID is not set # CONFIG_CMD_JFFS2 is not set CONFIG_CMD_MTDPARTS=y # CONFIG_CMD_MTDPARTS_SPREAD is not set # CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES is not set CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)" # CONFIG_CMD_REISER is not set # CONFIG_CMD_ZFS is not set # # Debug commands # # CONFIG_CMD_BEDBUG is not set # CONFIG_CMD_DIAG is not set # CONFIG_CMD_LOG is not set # CONFIG_CMD_TRACE is not set # CONFIG_CMD_UBI is not set # # Partition Types # CONFIG_PARTITIONS=y # CONFIG_MAC_PARTITION is not set CONFIG_DOS_PARTITION=y # CONFIG_ISO_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_EFI_PARTITION is not set CONFIG_PARTITION_UUIDS=y CONFIG_SUPPORT_OF_CONTROL=y CONFIG_DTC=y # # Device Tree Control # CONFIG_OF_CONTROL=y # CONFIG_OF_BOARD_FIXUP is not set # CONFIG_OF_LIVE is not set CONFIG_OF_SEPARATE=y # CONFIG_OF_EMBED is not set # CONFIG_OF_BOARD is not set # CONFIG_OF_PRIOR_STAGE is not set CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2" # CONFIG_MULTI_DTB_FIT is not set CONFIG_MKIMAGE_DTC_PATH="dtc" # # Environment # # CONFIG_ENV_IS_NOWHERE is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_SYS_RELOC_GD_ENV_ADDR is not set # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set # CONFIG_NET is not set # # Device Drivers # # # Generic Driver Options # CONFIG_DM=y CONFIG_DM_WARN=y # CONFIG_DM_DEBUG is not set # CONFIG_DM_DEVICE_REMOVE is not set CONFIG_DM_STDIO=y CONFIG_DM_SEQ_ALIAS=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_DEVRES is not set CONFIG_SIMPLE_BUS=y CONFIG_OF_TRANSLATE=y # CONFIG_TRANSLATION_OFFSET is not set CONFIG_DM_DEV_READ_INLINE=y # CONFIG_ADC is not set # CONFIG_ADC_EXYNOS is not set # CONFIG_ADC_SANDBOX is not set # CONFIG_SARADC_MESON is not set # CONFIG_SARADC_ROCKCHIP is not set # CONFIG_SATA is not set # CONFIG_SCSI_AHCI is not set # # SATA/SCSI device support # # CONFIG_DWC_AHSATA is not set # CONFIG_FSL_SATA is not set # CONFIG_MVSATA_IDE is not set # CONFIG_SATA_MV is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIL3114 is not set # CONFIG_AXI is not set CONFIG_BLK=y CONFIG_HAVE_BLOCK_DEVICE=y CONFIG_BLOCK_CACHE=y # CONFIG_IDE is not set # CONFIG_BOOTCOUNT_LIMIT is not set # # Cache Controller drivers # # CONFIG_CACHE is not set # CONFIG_NCORE_CACHE is not set # # Clock # CONFIG_CLK=y # CONFIG_CLK_CCF is not set # CONFIG_CLK_HSDK is not set # CONFIG_CLK_CDCE9XX is not set # CONFIG_CLK_AT91 is not set # CONFIG_CLK_SIFIVE is not set # CONFIG_ICS8N3QV01 is not set # CONFIG_CLK_MPC83XX is not set CONFIG_CLK_MTMIPS_GATE=y # CONFIG_CPU is not set # # Hardware crypto devices # # CONFIG_FSL_CAAM is not set # CONFIG_SYS_FSL_SEC_BE is not set # CONFIG_SYS_FSL_SEC_LE is not set # # Demo for driver model # # CONFIG_DM_DEMO is not set # CONFIG_BOARD is not set # # DFU support # # # DMA Support # # CONFIG_DMA is not set # CONFIG_TI_EDMA3 is not set # # Fastboot support # # CONFIG_FIRMWARE is not set # CONFIG_ZYNQMP_FIRMWARE is not set # # FPGA support # # CONFIG_FPGA_ALTERA is not set # CONFIG_FPGA_SOCFPGA is not set # CONFIG_FPGA_XILINX is not set # # GPIO Support # # CONFIG_GPIO_HOG is not set # CONFIG_ALTERA_PIO is not set # CONFIG_DWAPB_GPIO is not set # CONFIG_AT91_GPIO is not set # CONFIG_ATMEL_PIO4 is not set # CONFIG_DA8XX_GPIO is not set # CONFIG_INTEL_BROADWELL_GPIO is not set # CONFIG_INTEL_GPIO is not set # CONFIG_INTEL_ICH6_GPIO is not set # CONFIG_IMX_RGPIO2P is not set # CONFIG_HSDK_CREG_GPIO is not set # CONFIG_LPC32XX_GPIO is not set # CONFIG_MSM_GPIO is not set # CONFIG_MXC_GPIO is not set # CONFIG_MXS_GPIO is not set # CONFIG_CMD_PCA953X is not set # CONFIG_ROCKCHIP_GPIO is not set # CONFIG_XILINX_GPIO is not set # CONFIG_CMD_TCA642X is not set # CONFIG_TEGRA_GPIO is not set # CONFIG_TEGRA186_GPIO is not set # CONFIG_VYBRID_GPIO is not set # CONFIG_SIFIVE_GPIO is not set # CONFIG_DM_74X164 is not set # CONFIG_DM_PCA953X is not set # CONFIG_SPL_DM_PCA953X is not set # CONFIG_MPC8XXX_GPIO is not set CONFIG_MT7621_GPIO=y # # Hardware Spinlock Support # # CONFIG_DM_HWSPINLOCK is not set # # I2C support # # CONFIG_DM_I2C is not set # CONFIG_SYS_I2C_DW is not set # CONFIG_SYS_I2C_IMX_LPI2C is not set # CONFIG_SYS_I2C_MXC is not set # CONFIG_INPUT is not set # CONFIG_DM_KEYBOARD is not set # CONFIG_TEGRA_KEYBOARD is not set # CONFIG_TWL4030_INPUT is not set # # LED Support # CONFIG_LED=y CONFIG_LED_BLINK=y CONFIG_LED_GPIO=y # CONFIG_LED_STATUS is not set # # Mailbox Controller Support # # CONFIG_DM_MAILBOX is not set # # Memory Controller drivers # # # Multifunction device drivers # # CONFIG_MISC is not set # CONFIG_CROS_EC is not set # CONFIG_DS4510 is not set # CONFIG_FSL_SEC_MON is not set # CONFIG_NUVOTON_NCT6102D is not set # CONFIG_PWRSEQ is not set # CONFIG_PCA9551_LED is not set # CONFIG_TWL4030_LED is not set # CONFIG_WINBOND_W83627 is not set # CONFIG_FS_LOADER is not set # # MMC Host controller Support # CONFIG_MMC=y CONFIG_MMC_WRITE=y # CONFIG_MMC_BROKEN_CD is not set CONFIG_DM_MMC=y # CONFIG_MMC_SPI is not set # CONFIG_ARM_PL180_MMCI is not set CONFIG_MMC_QUIRKS=y # CONFIG_MMC_HW_PARTITIONING is not set # CONFIG_SUPPORT_EMMC_RPMB is not set # CONFIG_SUPPORT_EMMC_BOOT is not set # CONFIG_MMC_IO_VOLTAGE is not set # CONFIG_SPL_MMC_IO_VOLTAGE is not set # CONFIG_MMC_HS400_ES_SUPPORT is not set # CONFIG_SPL_MMC_HS400_ES_SUPPORT is not set # CONFIG_MMC_HS400_SUPPORT is not set # CONFIG_SPL_MMC_HS400_SUPPORT is not set # CONFIG_MMC_HS200_SUPPORT is not set # CONFIG_SPL_MMC_HS200_SUPPORT is not set CONFIG_MMC_VERBOSE=y # CONFIG_MMC_TRACE is not set # CONFIG_MMC_DW is not set # CONFIG_MMC_MXC is not set # CONFIG_MMC_PCI is not set # CONFIG_MMC_OMAP_HS is not set # CONFIG_MMC_SDHCI is not set # CONFIG_STM32_SDMMC2 is not set # CONFIG_FTSDC010 is not set CONFIG_MMC_MTK=y # CONFIG_FSL_ESDHC is not set # CONFIG_FSL_ESDHC_IMX is not set # # MTD Support # CONFIG_MTD_PARTITIONS=y CONFIG_MTD=y # CONFIG_DM_MTD is not set # CONFIG_MTD_NOR_FLASH is not set # CONFIG_FLASH_CFI_DRIVER is not set # CONFIG_HBMC_AM654 is not set # CONFIG_MTD_RAW_NAND is not set # # SPI Flash Support # CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=0 CONFIG_SF_DEFAULT_CS=0 CONFIG_SF_DEFAULT_MODE=3 CONFIG_SF_DEFAULT_SPEED=1000000 CONFIG_SPI_FLASH_SFDP_SUPPORT=y # CONFIG_SPI_FLASH_BAR is not set # CONFIG_SF_DUAL_FLASH is not set # CONFIG_SPI_FLASH_ATMEL is not set # CONFIG_SPI_FLASH_EON is not set CONFIG_SPI_FLASH_GIGADEVICE=y # CONFIG_SPI_FLASH_ISSI is not set # CONFIG_SPI_FLASH_MACRONIX is not set # CONFIG_SPI_FLASH_SPANSION is not set # CONFIG_SPI_FLASH_STMICRO is not set # CONFIG_SPI_FLASH_SST is not set # CONFIG_SPI_FLASH_WINBOND is not set # CONFIG_SPI_FLASH_XMC is not set CONFIG_SPI_FLASH_USE_4K_SECTORS=y # CONFIG_SPI_FLASH_DATAFLASH is not set CONFIG_SPI_FLASH_MTD=y # CONFIG_SPL_SPI_FLASH_MTD is not set # # UBI support # # CONFIG_UBI_SILENCE_MSG is not set # CONFIG_MTD_UBI is not set # CONFIG_BITBANGMII is not set # CONFIG_MV88E6352_SWITCH is not set # CONFIG_FSL_PFE is not set # CONFIG_DM_ETH is not set # CONFIG_PCI is not set # # PCI Endpoint # # CONFIG_PCI_ENDPOINT is not set # CONFIG_X86_PCH7 is not set # CONFIG_X86_PCH9 is not set # # PHY Subsystem # # CONFIG_PHY is not set # CONFIG_MVEBU_COMPHY_SUPPORT is not set # # Pin controllers # CONFIG_PINCTRL=y CONFIG_PINCTRL_FULL=y CONFIG_PINCTRL_GENERIC=y CONFIG_PINMUX=y CONFIG_PINCONF=y CONFIG_PINCONF_RECURSIVE=y # CONFIG_PINCTRL_AT91 is not set # CONFIG_PINCTRL_AT91PIO4 is not set # CONFIG_PINCTRL_INTEL is not set # CONFIG_PINCTRL_ROCKCHIP_RV1108 is not set # CONFIG_PINCTRL_SINGLE is not set # CONFIG_PINCTRL_STM32 is not set # CONFIG_PINCTRL_STMFX is not set CONFIG_PINCTRL_MTMIPS=y CONFIG_PINCTRL_MT7628=y # # Power # # CONFIG_ACPI_PMC is not set # CONFIG_SPL_ACPI_PMC is not set # CONFIG_TPL_ACPI_PMC is not set # # Power Domain Support # # CONFIG_POWER_DOMAIN is not set # CONFIG_DM_PMIC is not set # CONFIG_PMIC_AS3722 is not set # CONFIG_POWER_MC34VR500 is not set # CONFIG_DM_REGULATOR is not set # CONFIG_DM_PWM is not set # CONFIG_PWM_IMX is not set # CONFIG_PWM_SANDBOX is not set # CONFIG_U_QE is not set # CONFIG_RAM is not set # CONFIG_RAM_ROCKCHIP_DEBUG is not set # # Remote Processor drivers # # # Reset Controller Support # CONFIG_DM_RESET=y CONFIG_RESET_MTMIPS=y # CONFIG_RESET_HISILICON is not set # # Real Time Clock # # CONFIG_DM_RTC is not set # CONFIG_RTC_ENABLE_32KHZ_OUTPUT is not set # CONFIG_RTC_RX8025 is not set # CONFIG_RTC_PL031 is not set # CONFIG_RTC_S35392A is not set # CONFIG_RTC_MC146818 is not set # CONFIG_RTC_M41T62 is not set # CONFIG_SCSI is not set # CONFIG_DM_SCSI is not set # # Serial drivers # CONFIG_BAUDRATE=115200 CONFIG_REQUIRE_SERIAL_CONSOLE=y CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_SERIAL_PRESENT=y CONFIG_CONS_INDEX=3 CONFIG_DM_SERIAL=y # CONFIG_SERIAL_RX_BUFFER is not set # CONFIG_SERIAL_SEARCH_ALL is not set # CONFIG_DEBUG_UART_ALTERA_JTAGUART is not set # CONFIG_DEBUG_UART_ALTERA_UART is not set # CONFIG_DEBUG_UART_ATMEL is not set CONFIG_DEBUG_UART_NS16550=y # CONFIG_DEBUG_UART_S5P is not set # CONFIG_DEBUG_UART_UARTLITE is not set # CONFIG_DEBUG_UART_ARM_DCC is not set # CONFIG_DEBUG_MVEBU_A3700_UART is not set # CONFIG_DEBUG_UART_ZYNQ is not set # CONFIG_DEBUG_UART_PL010 is not set # CONFIG_DEBUG_UART_PL011 is not set # CONFIG_DEBUG_UART_SIFIVE is not set # CONFIG_DEBUG_UART_OMAP is not set # CONFIG_DEBUG_UART_MTK is not set CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y # CONFIG_DEBUG_UART_SKIP_INIT is not set # CONFIG_DEBUG_UART_NS16550_CHECK_ENABLED is not set # CONFIG_ALTERA_JTAG_UART is not set # CONFIG_ALTERA_UART is not set # CONFIG_ARC_SERIAL is not set # CONFIG_ATMEL_USART is not set # CONFIG_BCM6345_SERIAL is not set # CONFIG_FSL_LINFLEXUART is not set # CONFIG_FSL_LPUART is not set # CONFIG_MVEBU_A3700_UART is not set # CONFIG_MCFUART is not set # CONFIG_NULLDEV_SERIAL is not set # CONFIG_SYS_NS16550 is not set # CONFIG_PL01X_SERIAL is not set # CONFIG_MSM_SERIAL is not set # CONFIG_OMAP_SERIAL is not set # CONFIG_PXA_SERIAL is not set # CONFIG_SIFIVE_SERIAL is not set CONFIG_MTK_SERIAL=y # CONFIG_SMEM is not set # # Sound support # # CONFIG_SOUND is not set # # SOC (System On Chip) specific Drivers # # CONFIG_SOC_TI is not set CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_SPI_MEM=y # CONFIG_ALTERA_SPI is not set # CONFIG_ATCSPI200_SPI is not set # CONFIG_ATMEL_SPI is not set # CONFIG_BCMSTB_SPI is not set # CONFIG_CADENCE_QSPI is not set # CONFIG_CF_SPI is not set # CONFIG_DESIGNWARE_SPI is not set # CONFIG_EXYNOS_SPI is not set # CONFIG_FSL_DSPI is not set # CONFIG_ICH_SPI is not set # CONFIG_MPC8XXX_SPI is not set CONFIG_MT7621_SPI=y # CONFIG_MTK_SNFI_SPI is not set # CONFIG_MVEBU_A3700_SPI is not set # CONFIG_ROCKCHIP_SPI is not set # CONFIG_SPI_SIFIVE is not set # CONFIG_SPI_SUNXI is not set # CONFIG_TEGRA114_SPI is not set # CONFIG_TEGRA20_SFLASH is not set # CONFIG_TEGRA20_SLINK is not set # CONFIG_TEGRA210_QSPI is not set # CONFIG_TI_QSPI is not set # CONFIG_XILINX_SPI is not set # CONFIG_SOFT_SPI is not set # CONFIG_FSL_ESPI is not set # CONFIG_FSL_QSPI is not set # CONFIG_SH_QSPI is not set # CONFIG_KIRKWOOD_SPI is not set # CONFIG_MXC_SPI is not set # CONFIG_MXS_SPI is not set # CONFIG_OMAP3_SPI is not set # # SPMI support # # CONFIG_SPMI is not set # # System reset device drivers # CONFIG_SYSRESET=y # CONFIG_SYSRESET_GPIO is not set CONFIG_SYSRESET_SYSCON=y # CONFIG_SYSRESET_WATCHDOG is not set # CONFIG_SYSRESET_MPC83XX is not set # CONFIG_OPTEE is not set # CONFIG_DM_THERMAL is not set # # Timer Support # # CONFIG_TIMER is not set # # TPM support # CONFIG_USB=y CONFIG_DM_USB=y # CONFIG_DM_USB_GADGET is not set # # USB Host Controller Drivers # CONFIG_USB_HOST=y # CONFIG_USB_XHCI_HCD is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_MSM is not set # CONFIG_USB_EHCI_PCI is not set CONFIG_USB_EHCI_GENERIC=y # CONFIG_USB_EHCI_FSL is not set # CONFIG_USB_OHCI_HCD is not set # CONFIG_USB_OHCI_PCI is not set # CONFIG_USB_UHCI_HCD is not set # CONFIG_USB_DWC2 is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_CDNS3 is not set # CONFIG_USB_DWC3 is not set # # Legacy MUSB Support # # CONFIG_USB_MUSB_HCD is not set # CONFIG_USB_MUSB_UDC is not set # # MUSB Controller Driver # # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set # CONFIG_USB_MUSB_DA8XX is not set # CONFIG_USB_MUSB_TI is not set # CONFIG_USB_MUSB_AM35X is not set # CONFIG_USB_MUSB_DSPS is not set # CONFIG_USB_MUSB_PIO_ONLY is not set # # USB Phy # # CONFIG_TWL4030_USB is not set # CONFIG_OMAP_USB_PHY is not set # CONFIG_ROCKCHIP_USB2_PHY is not set # # ULPI drivers # # # USB peripherals # CONFIG_USB_STORAGE=y # CONFIG_USB_KEYBOARD is not set # CONFIG_USB_GADGET is not set # CONFIG_USB_HOST_ETHER is not set # # UFS Host Controller Support # # CONFIG_TI_J721E_UFS is not set # # Graphics support # # CONFIG_DM_VIDEO is not set # CONFIG_SYS_WHITE_ON_BLACK is not set # CONFIG_NO_FB_CLEAR is not set # # TrueType Fonts # # CONFIG_VIDEO_VESA is not set # CONFIG_VIDEO_LCD_ANX9804 is not set # CONFIG_VIDEO_LCD_SSD2828 is not set # CONFIG_VIDEO_MVEBU is not set # CONFIG_I2C_EDID is not set # CONFIG_DISPLAY is not set # CONFIG_VIDEO_TEGRA20 is not set # CONFIG_VIDEO_BRIDGE is not set # CONFIG_VIDEO is not set # CONFIG_LCD is not set # CONFIG_VIDEO_SIMPLE is not set # CONFIG_VIDEO_DT_SIMPLEFB is not set # CONFIG_OSD is not set # # VirtIO Drivers # # CONFIG_VIRTIO_MMIO is not set # # 1-Wire support # # CONFIG_W1 is not set # # 1-wire EEPROM support # # CONFIG_W1_EEPROM is not set # # Watchdog Timer Support # CONFIG_WATCHDOG=y CONFIG_WATCHDOG_TIMEOUT_MSECS=60000 # CONFIG_WATCHDOG_RESET_DISABLE is not set # CONFIG_IMX_WATCHDOG is not set # CONFIG_ULP_WATCHDOG is not set CONFIG_WDT=y # CONFIG_WDT_ASPEED is not set # CONFIG_WDT_AT91 is not set # CONFIG_WDT_CDNS is not set CONFIG_WDT_MT7621=y # CONFIG_WDT_ORION is not set # CONFIG_WDT_SP805 is not set # CONFIG_WDT_STM32MP is not set # CONFIG_XILINX_TB_WATCHDOG is not set # CONFIG_PHYS_TO_BUS is not set # # File systems # # CONFIG_FS_BTRFS is not set # CONFIG_FS_CBFS is not set # CONFIG_SPL_FS_CBFS is not set # CONFIG_FS_EXT4 is not set CONFIG_FS_FAT=y CONFIG_FAT_WRITE=y CONFIG_FS_FAT_MAX_CLUSTSIZE=65536 # CONFIG_FS_JFFS2 is not set # CONFIG_UBIFS_SILENCE_MSG is not set # CONFIG_FS_CRAMFS is not set # CONFIG_YAFFS2 is not set # # Library routines # # CONFIG_BCH is not set # CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED is not set # CONFIG_DYNAMIC_CRC_TABLE is not set CONFIG_HAVE_PRIVATE_LIBGCC=y CONFIG_LIB_UUID=y CONFIG_PRINTF=y CONFIG_SPRINTF=y CONFIG_STRTO=y CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_SYS_HZ=1000 # CONFIG_PANIC_HANG is not set # CONFIG_REGEX is not set CONFIG_LIB_RAND=y # CONFIG_LIB_HW_RAND is not set # CONFIG_SPL_TINY_MEMSET is not set # CONFIG_TPL_TINY_MEMSET is not set # CONFIG_BITREVERSE is not set # CONFIG_TRACE is not set # CONFIG_CMD_DHRYSTONE is not set # # Security support # # CONFIG_AES is not set # CONFIG_RSA is not set # CONFIG_ASYMMETRIC_KEY_TYPE is not set # CONFIG_TPM is not set # # Android Verified Boot # # # Hashing Support # # CONFIG_SHA1 is not set # CONFIG_SHA256 is not set # CONFIG_SHA_HW_ACCEL is not set # # Compression Support # # CONFIG_LZ4 is not set CONFIG_LZMA=y CONFIG_LZO=y CONFIG_GZIP=y CONFIG_ZLIB=y # CONFIG_ZSTD is not set # CONFIG_SPL_LZ4 is not set # CONFIG_SPL_LZO is not set # CONFIG_SPL_GZIP is not set # CONFIG_SPL_ZSTD is not set # CONFIG_ERRNO_STR is not set # CONFIG_HEXDUMP is not set CONFIG_OF_LIBFDT=y CONFIG_OF_LIBFDT_ASSUME_MASK=0 # CONFIG_OF_LIBFDT_OVERLAY is not set # CONFIG_SPL_OF_LIBFDT is not set # CONFIG_TPL_OF_LIBFDT is not set # CONFIG_FDT_FIXUP_PARTITIONS is not set # # System tables # # CONFIG_TEST_FDTDEC is not set # CONFIG_UNIT_TEST is not set ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-11 21:38 ` Mauro Condarelli @ 2020-01-11 23:58 ` Sean Anderson 2020-01-12 0:22 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Sean Anderson @ 2020-01-11 23:58 UTC (permalink / raw) To: u-boot On 1/11/20 4:38 PM, Mauro Condarelli wrote: > Thanks Joel, > unfortunately I already have that defined, even if I forgot to copy it. > I attach my full .config for reference as I have no idea what I'm > still missing. > > On 1/11/20 9:42 PM, Sean Anderson wrote: >>> Could You share a Linkit _defconfig with early serial debug enabled? >>> I'm decidedly missing something as, even enabling >>> >>> CONFIG_DEBUG_UART=y >>> CONFIG_DEBUG_UART_BASE=0x10000e00 >>> CONFIG_DEBUG_UART_CLOCK=20 >>> CONFIG_DEBUG_UART_SHIFT=2 >>> CONFIG_DEBUG_UART_ANNOUNCE=y So it looks like your clock is way too low. The unit for the clock is Hz. From the device tree you sent, this board is based off arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this board is compatible with "mediatek,mt7628-clk", and the driver is located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2 clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate, the peripheral clock source depends on the value of PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the data sheet). Therefore, the else clause is taken (unless configured otherwise), so you should use 40000000 for your clock. >> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. > As said I have it, but I'm not sure about the other parameters. > Maybe a better choice would be CONFIG_DEBUG_UART_MTK. > Having a "known good" configuration would help a lot. > > Regards > Mauro > ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-11 23:58 ` Sean Anderson @ 2020-01-12 0:22 ` Mauro Condarelli 0 siblings, 0 replies; 30+ messages in thread From: Mauro Condarelli @ 2020-01-12 0:22 UTC (permalink / raw) To: u-boot Many thanks. It appears I had completely misinterpreted the meaning of CONFIG_DEBUG_UART_CLOCK. I see now a correct output and a new warning message: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 right after "<debug_uart>" notification. Tomorrow I'll try to understand what it means. I don't think I would have found it without You pointing in the right direction. MANY Thanks! Best regards Mauro Condarelli On 1/12/20 12:58 AM, Sean Anderson wrote: > On 1/11/20 4:38 PM, Mauro Condarelli wrote: >> Thanks Joel, >> unfortunately I already have that defined, even if I forgot to copy it. >> I attach my full .config for reference as I have no idea what I'm >> still missing. >> >> On 1/11/20 9:42 PM, Sean Anderson wrote: >>>> Could You share a Linkit _defconfig with early serial debug enabled? >>>> I'm decidedly missing something as, even enabling >>>> >>>> CONFIG_DEBUG_UART=y >>>> CONFIG_DEBUG_UART_BASE=0x10000e00 >>>> CONFIG_DEBUG_UART_CLOCK=20 >>>> CONFIG_DEBUG_UART_SHIFT=2 >>>> CONFIG_DEBUG_UART_ANNOUNCE=y > So it looks like your clock is way too low. The unit for the clock is > Hz. From the device tree you sent, this board is based off > arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this > board is compatible with "mediatek,mt7628-clk", and the driver is > located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2 > clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate, > the peripheral clock source depends on the value of > PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the > data sheet). Therefore, the else clause is taken (unless configured > otherwise), so you should use 40000000 for your clock. > >>> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550. >> As said I have it, but I'm not sure about the other parameters. >> Maybe a better choice would be CONFIG_DEBUG_UART_MTK. >> Having a "known good" configuration would help a lot. >> >> Regards >> Mauro >> > ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-11 19:00 ` Mauro Condarelli 2020-01-11 20:42 ` Sean Anderson @ 2020-01-13 6:53 ` Stefan Roese 2020-01-13 10:24 ` Mauro Condarelli 1 sibling, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-13 6:53 UTC (permalink / raw) To: u-boot Hi Mauro, On 11.01.20 20:00, Mauro Condarelli wrote: > I managed to find ONE of the reasons why my ROM build didn't run: > I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. I see. This explains of course, why your board does not boot without any "preloader". > I wanted, nonetheless, be prepared for further mishaps, but > I have some other problems (see below). Are these issues now fixed? I scanned the discussion about the DEBUG UART on the list. Is this working for you now or do you have any other issues still? Did you successfully boot your new U-Boot from SPI NOR? <snip> >> You might also want to give the new version / patches from Weijie >> a try. He added SPL support and a "cleaner" init code for this SoC. > I'm interested in giving it a spin (and help debugging on another HW, > if needed), but I would like to have a solid base from where to move, > changing too many things at once is rarely a good strategy ;) I fully agree. Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 6:53 ` Stefan Roese @ 2020-01-13 10:24 ` Mauro Condarelli 2020-01-13 11:39 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-13 10:24 UTC (permalink / raw) To: u-boot Hi Stefan, On 1/13/20 7:53 AM, Stefan Roese wrote: > Hi Mauro, > > On 11.01.20 20:00, Mauro Condarelli wrote: >> I managed to find ONE of the reasons why my ROM build didn't run: >> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. > > I see. This explains of course, why your board does not boot without > any "preloader". > >> I wanted, nonetheless, be prepared for further mishaps, but >> I have some other problems (see below). > > Are these issues now fixed? I scanned the discussion about the DEBUG > UART on the list. Is this working for you now or do you have any other > issues still? Did you successfully boot your new U-Boot from SPI NOR? Yes and no :( I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure). I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl at 60 is not yet setup correctly?). This is the output I get from RAM-based u-boot: <debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus at 10000000', 'default'): pinctrl_select_state_full('uart2 at e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl at 0x2c', 'default'): U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) Model: VoCore2 DRAM: 128 MiB pinctrl_select_state_full('palmbus at 10000000', 'default'): pinctrl_select_state_full('pinctrl at 60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2 at e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl at 0x2c', 'default'): pinctrl_select_state_full('watchdog at 100', 'default'): WDT: Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m at 0', 'default'): pinctrl_select_state_full('mmc at 10130000', 'default'): mmc at 10130000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: uart2 at e00 Out: uart2 at e00 Err: uart2 at e00 Model: VoCore2 arch_misc_init(): => ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required). The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course! If I have to resort to that clumsy method, would be enough to put "new" in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 Did I forget something? > <snip> > >>> You might also want to give the new version / patches from Weijie >>> a try. He added SPL support and a "cleaner" init code for this SoC. >> I'm interested in giving it a spin (and help debugging on another HW, >> if needed), but I would like to have a solid base from where to move, >> changing too many things at once is rarely a good strategy ;) > > I fully agree. I need to be able to start from SPI NOR, before I can commit to some other task > Thanks, > Stefan Many thanks Mauro -------------- next part -------------- CONFIG_MIPS=y CONFIG_SYS_TEXT_BASE=0x9c000000 CONFIG_ENV_SIZE=0x00001000 CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BOARD_INIT=y CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=40000000 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y CONFIG_BOOT_ROM=y CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y CONFIG_MIPS_BOOT_FDT=y CONFIG_DEBUG_UART=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y CONFIG_SYS_BOOT_GET_KBD=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_USE_BOOTARGS=y CONFIG_LOGLEVEL=8 CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_ARCH_EARLY_INIT_R=y CONFIG_ARCH_MISC_INIT=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set # 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_XIMG is not set CONFIG_CMD_MEMINFO=y CONFIG_CMD_GPIO=y CONFIG_RANDOM_UUID=y # CONFIG_CMD_LOADB is not set # 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_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="spi0.0:504k(u-boot),4k(env),4k(factory),2688k(kernel),-(filesystem)" # CONFIG_ISO_PARTITION is not set 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_NET is not set # CONFIG_DM_DEVICE_REMOVE is not set # CONFIG_INPUT is not set 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_WINBOND=y CONFIG_SPI_FLASH_MTD=y # CONFIG_DM_ETH is not set # CONFIG_RAM_ROCKCHIP_DEBUG is not set CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=3 CONFIG_DEBUG_UART_MTK=y CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_SPI=y CONFIG_MT7621_SPI=y CONFIG_SYSRESET_SYSCON=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_LZMA=y CONFIG_LZO=y -------------- next part -------------- CONFIG_MIPS=y CONFIG_SYS_TEXT_BASE=0x80010000 CONFIG_ENV_SIZE=0x00001000 CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BOARD_INIT=y CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=40000000 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_VOCORE2=y CONFIG_MIPS_BOOT_FDT=y CONFIG_DEBUG_UART=y CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_SYS_BOOT_GET_CMDLINE=y CONFIG_SYS_BOOT_GET_KBD=y # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_USE_BOOTARGS=y CONFIG_LOGLEVEL=8 CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_ARCH_EARLY_INIT_R=y CONFIG_ARCH_MISC_INIT=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y # CONFIG_AUTOBOOT is not set # 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_XIMG is not set CONFIG_CMD_MEMINFO=y CONFIG_CMD_GPIO=y CONFIG_RANDOM_UUID=y # CONFIG_CMD_LOADB is not set # 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_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="spi0.0:504k(u-boot),4k(env),4k(factory),2688k(kernel),-(filesystem)" # CONFIG_ISO_PARTITION is not set 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_NET is not set # CONFIG_DM_DEVICE_REMOVE is not set # CONFIG_INPUT is not set 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_WINBOND=y CONFIG_SPI_FLASH_MTD=y # CONFIG_DM_ETH is not set # CONFIG_RAM_ROCKCHIP_DEBUG is not set CONFIG_SPECIFY_CONSOLE_INDEX=y CONFIG_CONS_INDEX=3 CONFIG_DEBUG_UART_MTK=y CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_SPI=y CONFIG_MT7621_SPI=y CONFIG_SYSRESET_SYSCON=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_LZMA=y CONFIG_LZO=y -------------- next part -------------- A non-text attachment was scrubbed... Name: board.c Type: text/x-csrc Size: 1333 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/e8d81960/attachment.c> -------------- next part -------------- A non-text attachment was scrubbed... Name: vocore2.h Type: text/x-chdr Size: 1159 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/e8d81960/attachment.h> ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 10:24 ` Mauro Condarelli @ 2020-01-13 11:39 ` Stefan Roese 2020-01-13 12:24 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-13 11:39 UTC (permalink / raw) To: u-boot Hi Mauro, On 13.01.20 11:24, Mauro Condarelli wrote: > On 1/13/20 7:53 AM, Stefan Roese wrote: >> Hi Mauro, >> >> On 11.01.20 20:00, Mauro Condarelli wrote: >>> I managed to find ONE of the reasons why my ROM build didn't run: >>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >> >> I see. This explains of course, why your board does not boot without >> any "preloader". >> >>> I wanted, nonetheless, be prepared for further mishaps, but >>> I have some other problems (see below). >> >> Are these issues now fixed? I scanned the discussion about the DEBUG >> UART on the list. Is this working for you now or do you have any other >> issues still? Did you successfully boot your new U-Boot from SPI NOR? > Yes and no :( > > I fixed my RAM-based problems, but booting from SPI NOR still refuses to > utter a single byte. > I do attach my defconfigs and my board.c for your reading pleasure (in > case you have troubles getting asleep they should provide a good cure). Before looking into this in more depth (I actually do have problems sleeping though, so I might take a look at it later ;)), why don't you re-start with your defconfig by using the linkit defconfig file. If you are lucky, the LinkIt binary might even work for the VoCore2. Or what are the differences except the SoC type and WLAN? Its the same DDR2 config and the same UART. So it might get you pretty far - also with ROM based booting. > I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c > and it > turns out system tries to setup pins for uart2, but fails (maybe because > pinctrl at 60 is not yet setup correctly?). > This is the output I get from RAM-based u-boot: > > <debug_uart> board_debug_uart_init(): > board_early_init_f(): > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > > U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('pinctrl at 60', 'default'): > pinctrl_select_state_full('pin_state', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full('uart2_pins', 'default'): > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > pinctrl_select_state_full('watchdog at 100', 'default'): > WDT: Started with servicing (60s timeout) > board_early_init_r(): > arch_early_init_r(): > MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): > pinctrl_select_state_full('sd_iot_mode', 'default'): > pinctrl_select_state_full('clk48m at 0', 'default'): > pinctrl_select_state_full('mmc at 10130000', 'default'): > mmc at 10130000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: uart2 at e00 > Out: uart2 at e00 > Err: uart2 at e00 > Model: VoCore2 > arch_misc_init(): > => I don't have all these pinctrl issues on LinkIt. I suspect a config issue and / or dts issue. Please compare. > > ROM-based u-boot, as said, does not print *anything*, not even garbage. > I'm beginning to suspect I have some mishap with start address or similar. > I have absolutely no idea how to debug this without a JTAG probe (which > I don't have and would be non-trivial to get working; soldering required). Yes. JTAG requires soldering IIRC. > The only idea I currently have is to modify my "old" u-boot to do > initialization > and then jump to beginning of "new" u-boot. > If I can make it work in an automatic way I can try removing > initialization steps > till I find the "culprit". > Any better idea would be welcome, of course! > > If I have to resort to that clumsy method, would be enough to put "new" > in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only > 183272 bytes long) and jump to the first location? > I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 This is the TEXT_BASE for ROM based booting: CONFIG_SYS_TEXT_BASE=0x9c000000 Please see configs/linkit-smart-7688_defconfig. > Did I forget something? Not sure. I still think using the linkit port as a base for SPI NOR based booting would be a very good test at least. Do you see any problems with this approach (board / SoC differences)? Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 11:39 ` Stefan Roese @ 2020-01-13 12:24 ` Mauro Condarelli 2020-01-13 12:45 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-13 12:24 UTC (permalink / raw) To: u-boot On 1/13/20 12:39 PM, Stefan Roese wrote: > Hi Mauro, > > On 13.01.20 11:24, Mauro Condarelli wrote: >> On 1/13/20 7:53 AM, Stefan Roese wrote: >>> Hi Mauro, >>> >>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>> >>> I see. This explains of course, why your board does not boot without >>> any "preloader". >>> >>>> I wanted, nonetheless, be prepared for further mishaps, but >>>> I have some other problems (see below). >>> >>> Are these issues now fixed? I scanned the discussion about the DEBUG >>> UART on the list. Is this working for you now or do you have any other >>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >> Yes and no :( >> >> I fixed my RAM-based problems, but booting from SPI NOR still refuses to >> utter a single byte. >> I do attach my defconfigs and my board.c for your reading pleasure (in >> case you have troubles getting asleep they should provide a good cure). > > Before looking into this in more depth (I actually do have problems > sleeping > though, so I might take a look at it later ;)), why don't you re-start > with > your defconfig by using the linkit defconfig file. If you are lucky, the > LinkIt binary might even work for the VoCore2. Or what are the > differences > except the SoC type and WLAN? Its the same DDR2 config and the same UART. > So it might get you pretty far - also with ROM based booting. I will try it. Just to be on the safe side, could You attach a binary (or two: ROM and RAM) to the mail? If it works it would really give me a start base. >> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >> and it >> turns out system tries to setup pins for uart2, but fails (maybe because >> pinctrl at 60 is not yet setup correctly?). >> This is the output I get from RAM-based u-boot: >> >> <debug_uart> board_debug_uart_init(): >> board_early_init_f(): >> pinctrl_select_state_full('palmbus at 10000000', 'default'): >> pinctrl_select_state_full('uart2 at e00', 'default'): >> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >> >> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >> Model: VoCore2 >> DRAM: 128 MiB >> pinctrl_select_state_full('palmbus at 10000000', 'default'): >> pinctrl_select_state_full('pinctrl at 60', 'default'): >> pinctrl_select_state_full('pin_state', 'default'): >> pinctrl_select_state_full('uart2 at e00', 'default'): >> pinctrl_select_state_full('uart2_pins', 'default'): >> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >> pinctrl_select_state_full('watchdog at 100', 'default'): >> WDT: Started with servicing (60s timeout) >> board_early_init_r(): >> arch_early_init_r(): >> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >> pinctrl_select_state_full('sd_iot_mode', 'default'): >> pinctrl_select_state_full('clk48m at 0', 'default'): >> pinctrl_select_state_full('mmc at 10130000', 'default'): >> mmc at 10130000: 0 >> Loading Environment from FAT... *** Warning - bad CRC, using default >> environment >> >> In: uart2 at e00 >> Out: uart2 at e00 >> Err: uart2 at e00 >> Model: VoCore2 >> arch_misc_init(): >> => > > I don't have all these pinctrl issues on LinkIt. I suspect a config > issue and / or dts issue. Please compare. I will, but I was trying to say something different: Apparently the stock software tries to initialize uart2 pinctrl and it *seems* to succeed later in initialization. This *seems* to indicate explicit pin setup in board_early_init_f() is not strictly needed (we would lose only the first few lines even if we don't fix the error). I had a look to pinctrl-mt7628.c and it seems to do the right thing upon call to ('uart2_pins', 'default'), so anything after that *should* work even without low-level setup. >> >> ROM-based u-boot, as said, does not print *anything*, not even garbage. >> I'm beginning to suspect I have some mishap with start address or >> similar. >> I have absolutely no idea how to debug this without a JTAG probe (which >> I don't have and would be non-trivial to get working; soldering >> required). > > Yes. JTAG requires soldering IIRC. > >> The only idea I currently have is to modify my "old" u-boot to do >> initialization >> and then jump to beginning of "new" u-boot. >> If I can make it work in an automatic way I can try removing >> initialization steps >> till I find the "culprit". >> Any better idea would be welcome, of course! >> >> If I have to resort to that clumsy method, would be enough to put "new" >> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >> only >> 183272 bytes long) and jump to the first location? >> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 > > This is the TEXT_BASE for ROM based booting: > > CONFIG_SYS_TEXT_BASE=0x9c000000 AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory region, the latter being uncached. I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some space for "old" (possibly crippled) u-boot doing initialization and then "jumping" to "new". > Please see configs/linkit-smart-7688_defconfig. > >> Did I forget something? > > Not sure. I still think using the linkit port as a base for SPI NOR > based booting would be a very good test at least. Do you see any > problems with this approach (board / SoC differences)? No. I see no troubles, for a basic startup. MMC would probably need some changes, but that can come later. As said: I would like to try a prebuilt binary as first thing, so I can be sure I have no other problems (like gcc version or other local variations); then I would try to reproduce locally the equivalent binary with no changes and finally I would try to incorporate my specific needs. What do You think? > Thanks, > Stefan Best regards and TiA! Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 12:24 ` Mauro Condarelli @ 2020-01-13 12:45 ` Stefan Roese 2020-01-13 14:14 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-13 12:45 UTC (permalink / raw) To: u-boot On 13.01.20 13:24, Mauro Condarelli wrote: > > > On 1/13/20 12:39 PM, Stefan Roese wrote: >> Hi Mauro, >> >> On 13.01.20 11:24, Mauro Condarelli wrote: >>> On 1/13/20 7:53 AM, Stefan Roese wrote: >>>> Hi Mauro, >>>> >>>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>>> >>>> I see. This explains of course, why your board does not boot without >>>> any "preloader". >>>> >>>>> I wanted, nonetheless, be prepared for further mishaps, but >>>>> I have some other problems (see below). >>>> >>>> Are these issues now fixed? I scanned the discussion about the DEBUG >>>> UART on the list. Is this working for you now or do you have any other >>>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >>> Yes and no :( >>> >>> I fixed my RAM-based problems, but booting from SPI NOR still refuses to >>> utter a single byte. >>> I do attach my defconfigs and my board.c for your reading pleasure (in >>> case you have troubles getting asleep they should provide a good cure). >> >> Before looking into this in more depth (I actually do have problems >> sleeping >> though, so I might take a look at it later ;)), why don't you re-start >> with >> your defconfig by using the linkit defconfig file. If you are lucky, the >> LinkIt binary might even work for the VoCore2. Or what are the >> differences >> except the SoC type and WLAN? Its the same DDR2 config and the same UART. >> So it might get you pretty far - also with ROM based booting. > I will try it. > Just to be on the safe side, could You attach a binary (or two: ROM and > RAM) to > the mail? If it works it would really give me a start base. See below. >>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >>> and it >>> turns out system tries to setup pins for uart2, but fails (maybe because >>> pinctrl at 60 is not yet setup correctly?). >>> This is the output I get from RAM-based u-boot: >>> >>> <debug_uart> board_debug_uart_init(): >>> board_early_init_f(): >>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>> pinctrl_select_state_full('uart2 at e00', 'default'): >>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>> >>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>> >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>> Model: VoCore2 >>> DRAM: 128 MiB >>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>> pinctrl_select_state_full('pinctrl at 60', 'default'): >>> pinctrl_select_state_full('pin_state', 'default'): >>> pinctrl_select_state_full('uart2 at e00', 'default'): >>> pinctrl_select_state_full('uart2_pins', 'default'): >>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>> pinctrl_select_state_full('watchdog at 100', 'default'): >>> WDT: Started with servicing (60s timeout) >>> board_early_init_r(): >>> arch_early_init_r(): >>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>> pinctrl_select_state_full('sd_iot_mode', 'default'): >>> pinctrl_select_state_full('clk48m at 0', 'default'): >>> pinctrl_select_state_full('mmc at 10130000', 'default'): >>> mmc at 10130000: 0 >>> Loading Environment from FAT... *** Warning - bad CRC, using default >>> environment >>> >>> In: uart2 at e00 >>> Out: uart2 at e00 >>> Err: uart2 at e00 >>> Model: VoCore2 >>> arch_misc_init(): >>> => >> >> I don't have all these pinctrl issues on LinkIt. I suspect a config >> issue and / or dts issue. Please compare. > I will, but I was trying to say something different: > Apparently the stock software tries to initialize uart2 pinctrl and it > *seems* to succeed later in initialization. > This *seems* to indicate explicit pin setup in board_early_init_f() is > not strictly needed (we would lose only the first few lines even if > we don't fix the error). > I had a look to pinctrl-mt7628.c and it seems to do the right thing > upon call to ('uart2_pins', 'default'), so anything after that *should* > work even without low-level setup. You might be correct here. So this explicit pin-muxing for UART2 is only needed when DEBUG UART is used. This makes the code a bit clearer and smaller. Lets keep it on our list to remove this, once all this is resolved. >>> >>> ROM-based u-boot, as said, does not print *anything*, not even garbage. >>> I'm beginning to suspect I have some mishap with start address or >>> similar. >>> I have absolutely no idea how to debug this without a JTAG probe (which >>> I don't have and would be non-trivial to get working; soldering >>> required). >> >> Yes. JTAG requires soldering IIRC. >> >>> The only idea I currently have is to modify my "old" u-boot to do >>> initialization >>> and then jump to beginning of "new" u-boot. >>> If I can make it work in an automatic way I can try removing >>> initialization steps >>> till I find the "culprit". >>> Any better idea would be welcome, of course! >>> >>> If I have to resort to that clumsy method, would be enough to put "new" >>> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >>> only >>> 183272 bytes long) and jump to the first location? >>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 >> >> This is the TEXT_BASE for ROM based booting: >> >> CONFIG_SYS_TEXT_BASE=0x9c000000 > AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory > region, the latter being uncached. > I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some > space for "old" (possibly crippled) u-boot doing initialization and then > "jumping" > to "new". I see. Please give the LinkIt version a try first. This sounds easier (if it works) and more promising for my taste. >> Please see configs/linkit-smart-7688_defconfig. >> >>> Did I forget something? >> >> Not sure. I still think using the linkit port as a base for SPI NOR >> based booting would be a very good test at least. Do you see any >> problems with this approach (board / SoC differences)? > No. I see no troubles, for a basic startup. > MMC would probably need some changes, but that can come later. Yes. This test is just for basic very low level bootup checking. If this works, then you can use it as a basis to fine-tune your VoCore2 version from it by changing MMC etc support. > As said: I would like to try a prebuilt binary as first thing, so I can > be sure I have no other problems (like gcc version or other local > variations); then I would try to reproduce locally the equivalent binary > with no changes and finally I would try to incorporate my specific > needs. > What do You think? Please find attached the current mainline versions for LinkIt, one for RAM booting and one for ROM booting (in SPI NOR). I checked both version and they work fine on my LinkIt 7688 board: U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100) CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) Model: LinkIt-Smart-7688 DRAM: 128 MiB Loading Environment from SPI Flash... SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB OK Net: eth0: eth at 10110000 Hit any key to stop autoboot: 0 => Thanks, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: u-boot.bin-rom Type: application/octet-stream Size: 455708 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/afa44818/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: u-boot.bin-ram Type: application/octet-stream Size: 453724 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200113/afa44818/attachment-0003.obj> ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 12:45 ` Stefan Roese @ 2020-01-13 14:14 ` Mauro Condarelli 2020-01-13 23:08 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-13 14:14 UTC (permalink / raw) To: u-boot Hi Stefan, unfortunately it does *not* work. Ram based is ok, but rom is just as silent as mine: => usb start; sf probe; starting USB... Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): USB EHCI 1.00 scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found pinctrl_select_state_full('spi at b00', 'default'): SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load usb 0:1 85000000 u-boot_linkit.bin-rom 455708 bytes read in 22 ms (19.8 MiB/s) => sf update ${fileaddr} 0 ${filesize} device 0 offset 0x0, size 0x6f41c 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s => reset resetting ... pinctrl_select_state_full('syscon-reboot', 'default'): pinctrl_select_state_full('system-controller at 0', 'default'): I might have done something stupid; Now I need do stop, but I'll test again this evening. Many thanks Mauro On 1/13/20 1:45 PM, Stefan Roese wrote: > On 13.01.20 13:24, Mauro Condarelli wrote: >> >> >> On 1/13/20 12:39 PM, Stefan Roese wrote: >>> Hi Mauro, >>> >>> On 13.01.20 11:24, Mauro Condarelli wrote: >>>> On 1/13/20 7:53 AM, Stefan Roese wrote: >>>>> Hi Mauro, >>>>> >>>>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>>>> >>>>> I see. This explains of course, why your board does not boot without >>>>> any "preloader". >>>>> >>>>>> I wanted, nonetheless, be prepared for further mishaps, but >>>>>> I have some other problems (see below). >>>>> >>>>> Are these issues now fixed? I scanned the discussion about the DEBUG >>>>> UART on the list. Is this working for you now or do you have any >>>>> other >>>>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >>>> Yes and no :( >>>> >>>> I fixed my RAM-based problems, but booting from SPI NOR still >>>> refuses to >>>> utter a single byte. >>>> I do attach my defconfigs and my board.c for your reading pleasure >>>> (in >>>> case you have troubles getting asleep they should provide a good >>>> cure). >>> >>> Before looking into this in more depth (I actually do have problems >>> sleeping >>> though, so I might take a look at it later ;)), why don't you re-start >>> with >>> your defconfig by using the linkit defconfig file. If you are lucky, >>> the >>> LinkIt binary might even work for the VoCore2. Or what are the >>> differences >>> except the SoC type and WLAN? Its the same DDR2 config and the same >>> UART. >>> So it might get you pretty far - also with ROM based booting. >> I will try it. >> Just to be on the safe side, could You attach a binary (or two: ROM and >> RAM) to >> the mail? If it works it would really give me a start base. > > See below. > >>>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >>>> and it >>>> turns out system tries to setup pins for uart2, but fails (maybe >>>> because >>>> pinctrl at 60 is not yet setup correctly?). >>>> This is the output I get from RAM-based u-boot: >>>> >>>> <debug_uart> board_debug_uart_init(): >>>> board_early_init_f(): >>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>> >>>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>>> >>>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>>> Model: VoCore2 >>>> DRAM: 128 MiB >>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>> pinctrl_select_state_full('pinctrl at 60', 'default'): >>>> pinctrl_select_state_full('pin_state', 'default'): >>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>> pinctrl_select_state_full('uart2_pins', 'default'): >>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>> pinctrl_select_state_full('watchdog at 100', 'default'): >>>> WDT: Started with servicing (60s timeout) >>>> board_early_init_r(): >>>> arch_early_init_r(): >>>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>>> pinctrl_select_state_full('sd_iot_mode', 'default'): >>>> pinctrl_select_state_full('clk48m at 0', 'default'): >>>> pinctrl_select_state_full('mmc at 10130000', 'default'): >>>> mmc at 10130000: 0 >>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>> environment >>>> >>>> In: uart2 at e00 >>>> Out: uart2 at e00 >>>> Err: uart2 at e00 >>>> Model: VoCore2 >>>> arch_misc_init(): >>>> => >>> >>> I don't have all these pinctrl issues on LinkIt. I suspect a config >>> issue and / or dts issue. Please compare. >> I will, but I was trying to say something different: >> Apparently the stock software tries to initialize uart2 pinctrl and it >> *seems* to succeed later in initialization. >> This *seems* to indicate explicit pin setup in board_early_init_f() is >> not strictly needed (we would lose only the first few lines even if >> we don't fix the error). >> I had a look to pinctrl-mt7628.c and it seems to do the right thing >> upon call to ('uart2_pins', 'default'), so anything after that *should* >> work even without low-level setup. > > You might be correct here. So this explicit pin-muxing for UART2 is > only needed when DEBUG UART is used. This makes the code a bit clearer > and smaller. Lets keep it on our list to remove this, once all this > is resolved. > >>>> >>>> ROM-based u-boot, as said, does not print *anything*, not even >>>> garbage. >>>> I'm beginning to suspect I have some mishap with start address or >>>> similar. >>>> I have absolutely no idea how to debug this without a JTAG probe >>>> (which >>>> I don't have and would be non-trivial to get working; soldering >>>> required). >>> >>> Yes. JTAG requires soldering IIRC. >>> >>>> The only idea I currently have is to modify my "old" u-boot to do >>>> initialization >>>> and then jump to beginning of "new" u-boot. >>>> If I can make it work in an automatic way I can try removing >>>> initialization steps >>>> till I find the "culprit". >>>> Any better idea would be welcome, of course! >>>> >>>> If I have to resort to that clumsy method, would be enough to put >>>> "new" >>>> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >>>> only >>>> 183272 bytes long) and jump to the first location? >>>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 >>> >>> This is the TEXT_BASE for ROM based booting: >>> >>> CONFIG_SYS_TEXT_BASE=0x9c000000 >> AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory >> region, the latter being uncached. >> I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some >> space for "old" (possibly crippled) u-boot doing initialization and then >> "jumping" >> to "new". > > I see. Please give the LinkIt version a try first. This sounds easier > (if it works) and more promising for my taste. > >>> Please see configs/linkit-smart-7688_defconfig. >>> >>>> Did I forget something? >>> >>> Not sure. I still think using the linkit port as a base for SPI NOR >>> based booting would be a very good test at least. Do you see any >>> problems with this approach (board / SoC differences)? >> No. I see no troubles, for a basic startup. >> MMC would probably need some changes, but that can come later. > > Yes. This test is just for basic very low level bootup checking. If > this works, then you can use it as a basis to fine-tune your VoCore2 > version from it by changing MMC etc support. > >> As said: I would like to try a prebuilt binary as first thing, so I can >> be sure I have no other problems (like gcc version or other local >> variations); then I would try to reproduce locally the equivalent binary >> with no changes and finally I would try to incorporate my specific >> needs. >> What do You think? > > Please find attached the current mainline versions for LinkIt, one > for RAM booting and one for ROM booting (in SPI NOR). I checked both > version and they work fine on my LinkIt 7688 board: > > U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) > Model: LinkIt-Smart-7688 > DRAM: 128 MiB > Loading Environment from SPI Flash... SF: Detected mx25l25635e with > page size 256 Bytes, erase size 64 KiB, total 32 MiB > OK > Net: eth0: eth at 10110000 > Hit any key to stop autoboot: 0 > => > > > Thanks, > Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 14:14 ` Mauro Condarelli @ 2020-01-13 23:08 ` Mauro Condarelli 2020-01-14 11:03 ` Mauro Condarelli 2020-01-14 23:55 ` Debugging VoCore2 ROM Startup (was: How to debug HW startup?) Mauro Condarelli 0 siblings, 2 replies; 30+ messages in thread From: Mauro Condarelli @ 2020-01-13 23:08 UTC (permalink / raw) To: u-boot Next episode of this telenovela: I rebuilt u-boot for ROM at BC030000 (my code, very similar to LinkIt). I flashed it at 30000 in SPI NOR: => usb start; sf probe starting USB... Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): USB EHCI 1.00 scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load usb 0:1 85000000 u-boot.secondary 390089 bytes read in 18 ms (20.7 MiB/s) => sf update ${fileaddr} 30000 ${filesize} device 0 offset 0x30000, size 0x5f3c9 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s => reset Restarted old u-boot and jumped to new: U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) VoCore2 > go bc030000 ## Starting application at 0xBC030000 ... board_debug_uart_init(): <debug_uart> System stopped here several minutes, enough for me to start writing this email, then it continued boot sequence: board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus at 10000000', 'default'): pinctrl_select_state_full('uart2 at e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl at 0x2c', 'default'): U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100) CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) Model: VoCore2 DRAM: 128 MiB pinctrl_select_state_full('palmbus at 10000000', 'default'): pinctrl_select_state_full('pinctrl at 60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2 at e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl at 0x2c', 'default'): pinctrl_select_state_full('watchdog at 100', 'default'): WDT: Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m at 0', 'default'): pinctrl_select_state_full('mmc at 10130000', 'default'): mmc at 10130000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: uart2 at e00 Out: uart2 at e00 Err: uart2 at e00 Model: VoCore2 arch_misc_init(): => Code, beside being targeted to ROM and with a different SYS_TEXT_BASE, is identical to what runs fine when started from RAM. I also tried copying flash to ram: => cp.b bc030000 80010000 5f3c9 => go 80010000 ## Starting application at 0x80010000 ... board_debug_uart_init(): <debug_uart> [04010D08][04010D08] DDR Calibration DQS reg = 00008888 relocate_code Pointer at: 87f5c000 *********************** Watchdog Reset Occurred *********************** ... but this is almost expected because I relocated at another address without changing SYS_TEXT_BASE. A further measurement shows booting u-boot from flash stops for almost 5 minutes (4m48s, using a manual stopwatch). I sincerely have no idea where to bang my head :( TiA Mauro On 1/13/20 3:14 PM, Mauro Condarelli wrote: > Hi Stefan, > unfortunately it does *not* work. > > Ram based is ok, but rom is just as silent as mine: > > => usb start; sf probe; > starting USB... > Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): > USB EHCI 1.00 > scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > pinctrl_select_state_full('spi at b00', 'default'): > SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total > 16 MiB > => load usb 0:1 85000000 u-boot_linkit.bin-rom > 455708 bytes read in 22 ms (19.8 MiB/s) > => sf update ${fileaddr} 0 ${filesize} > device 0 offset 0x0, size 0x6f41c > 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s > => reset > resetting ... > pinctrl_select_state_full('syscon-reboot', 'default'): > pinctrl_select_state_full('system-controller at 0', 'default'): > > I might have done something stupid; Now I need do stop, but I'll > test again this evening. > > Many thanks > Mauro > > > On 1/13/20 1:45 PM, Stefan Roese wrote: >> On 13.01.20 13:24, Mauro Condarelli wrote: >>> >>> On 1/13/20 12:39 PM, Stefan Roese wrote: >>>> Hi Mauro, >>>> >>>> On 13.01.20 11:24, Mauro Condarelli wrote: >>>>> On 1/13/20 7:53 AM, Stefan Roese wrote: >>>>>> Hi Mauro, >>>>>> >>>>>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>>>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>>>>> I see. This explains of course, why your board does not boot without >>>>>> any "preloader". >>>>>> >>>>>>> I wanted, nonetheless, be prepared for further mishaps, but >>>>>>> I have some other problems (see below). >>>>>> Are these issues now fixed? I scanned the discussion about the DEBUG >>>>>> UART on the list. Is this working for you now or do you have any >>>>>> other >>>>>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >>>>> Yes and no :( >>>>> >>>>> I fixed my RAM-based problems, but booting from SPI NOR still >>>>> refuses to >>>>> utter a single byte. >>>>> I do attach my defconfigs and my board.c for your reading pleasure >>>>> (in >>>>> case you have troubles getting asleep they should provide a good >>>>> cure). >>>> Before looking into this in more depth (I actually do have problems >>>> sleeping >>>> though, so I might take a look at it later ;)), why don't you re-start >>>> with >>>> your defconfig by using the linkit defconfig file. If you are lucky, >>>> the >>>> LinkIt binary might even work for the VoCore2. Or what are the >>>> differences >>>> except the SoC type and WLAN? Its the same DDR2 config and the same >>>> UART. >>>> So it might get you pretty far - also with ROM based booting. >>> I will try it. >>> Just to be on the safe side, could You attach a binary (or two: ROM and >>> RAM) to >>> the mail? If it works it would really give me a start base. >> See below. >> >>>>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >>>>> and it >>>>> turns out system tries to setup pins for uart2, but fails (maybe >>>>> because >>>>> pinctrl at 60 is not yet setup correctly?). >>>>> This is the output I get from RAM-based u-boot: >>>>> >>>>> <debug_uart> board_debug_uart_init(): >>>>> board_early_init_f(): >>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>> >>>>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>>>> >>>>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>>>> Model: VoCore2 >>>>> DRAM: 128 MiB >>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>> pinctrl_select_state_full('pinctrl at 60', 'default'): >>>>> pinctrl_select_state_full('pin_state', 'default'): >>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>> pinctrl_select_state_full('uart2_pins', 'default'): >>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>> pinctrl_select_state_full('watchdog at 100', 'default'): >>>>> WDT: Started with servicing (60s timeout) >>>>> board_early_init_r(): >>>>> arch_early_init_r(): >>>>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>> pinctrl_select_state_full('sd_iot_mode', 'default'): >>>>> pinctrl_select_state_full('clk48m at 0', 'default'): >>>>> pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>> mmc at 10130000: 0 >>>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>>> environment >>>>> >>>>> In: uart2 at e00 >>>>> Out: uart2 at e00 >>>>> Err: uart2 at e00 >>>>> Model: VoCore2 >>>>> arch_misc_init(): >>>>> => >>>> I don't have all these pinctrl issues on LinkIt. I suspect a config >>>> issue and / or dts issue. Please compare. >>> I will, but I was trying to say something different: >>> Apparently the stock software tries to initialize uart2 pinctrl and it >>> *seems* to succeed later in initialization. >>> This *seems* to indicate explicit pin setup in board_early_init_f() is >>> not strictly needed (we would lose only the first few lines even if >>> we don't fix the error). >>> I had a look to pinctrl-mt7628.c and it seems to do the right thing >>> upon call to ('uart2_pins', 'default'), so anything after that *should* >>> work even without low-level setup. >> You might be correct here. So this explicit pin-muxing for UART2 is >> only needed when DEBUG UART is used. This makes the code a bit clearer >> and smaller. Lets keep it on our list to remove this, once all this >> is resolved. >> >>>>> ROM-based u-boot, as said, does not print *anything*, not even >>>>> garbage. >>>>> I'm beginning to suspect I have some mishap with start address or >>>>> similar. >>>>> I have absolutely no idea how to debug this without a JTAG probe >>>>> (which >>>>> I don't have and would be non-trivial to get working; soldering >>>>> required). >>>> Yes. JTAG requires soldering IIRC. >>>> >>>>> The only idea I currently have is to modify my "old" u-boot to do >>>>> initialization >>>>> and then jump to beginning of "new" u-boot. >>>>> If I can make it work in an automatic way I can try removing >>>>> initialization steps >>>>> till I find the "culprit". >>>>> Any better idea would be welcome, of course! >>>>> >>>>> If I have to resort to that clumsy method, would be enough to put >>>>> "new" >>>>> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >>>>> only >>>>> 183272 bytes long) and jump to the first location? >>>>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 >>>> This is the TEXT_BASE for ROM based booting: >>>> >>>> CONFIG_SYS_TEXT_BASE=0x9c000000 >>> AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory >>> region, the latter being uncached. >>> I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some >>> space for "old" (possibly crippled) u-boot doing initialization and then >>> "jumping" >>> to "new". >> I see. Please give the LinkIt version a try first. This sounds easier >> (if it works) and more promising for my taste. >> >>>> Please see configs/linkit-smart-7688_defconfig. >>>> >>>>> Did I forget something? >>>> Not sure. I still think using the linkit port as a base for SPI NOR >>>> based booting would be a very good test at least. Do you see any >>>> problems with this approach (board / SoC differences)? >>> No. I see no troubles, for a basic startup. >>> MMC would probably need some changes, but that can come later. >> Yes. This test is just for basic very low level bootup checking. If >> this works, then you can use it as a basis to fine-tune your VoCore2 >> version from it by changing MMC etc support. >> >>> As said: I would like to try a prebuilt binary as first thing, so I can >>> be sure I have no other problems (like gcc version or other local >>> variations); then I would try to reproduce locally the equivalent binary >>> with no changes and finally I would try to incorporate my specific >>> needs. >>> What do You think? >> Please find attached the current mainline versions for LinkIt, one >> for RAM booting and one for ROM booting (in SPI NOR). I checked both >> version and they work fine on my LinkIt 7688 board: >> >> U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100) >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) >> Model: LinkIt-Smart-7688 >> DRAM: 128 MiB >> Loading Environment from SPI Flash... SF: Detected mx25l25635e with >> page size 256 Bytes, erase size 64 KiB, total 32 MiB >> OK >> Net: eth0: eth at 10110000 >> Hit any key to stop autoboot: 0 >> => >> >> >> Thanks, >> Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* How to debug HW startup? 2020-01-13 23:08 ` Mauro Condarelli @ 2020-01-14 11:03 ` Mauro Condarelli 2020-01-14 23:55 ` Debugging VoCore2 ROM Startup (was: How to debug HW startup?) Mauro Condarelli 1 sibling, 0 replies; 30+ messages in thread From: Mauro Condarelli @ 2020-01-14 11:03 UTC (permalink / raw) To: u-boot Hi Stefan, update, see below. On 1/14/20 12:08 AM, Mauro Condarelli wrote: > Next episode of this telenovela: > > I rebuilt u-boot for ROM at BC030000 (my code, very similar to LinkIt). > I flashed it at 30000 in SPI NOR: > > => usb start; sf probe > starting USB... > Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): > USB EHCI 1.00 > scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total > 16 MiB > => load usb 0:1 85000000 u-boot.secondary > 390089 bytes read in 18 ms (20.7 MiB/s) > => sf update ${fileaddr} 30000 ${filesize} > device 0 offset 0x30000, size 0x5f3c9 > 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s > => reset > > Restarted old u-boot and jumped to new: > > U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) > VoCore2 > go bc030000 > ## Starting application at 0xBC030000 ... > board_debug_uart_init(): > <debug_uart> > System stopped here several minutes, enough for me to start writing > this email, then it continued boot sequence: > board_debug_uart_init(): > board_early_init_f(): Here is the first strange thing: apparently `board_debug_uart_init()` is called twice. I am not 100% sure as code is full of `#ifdef`s, but it seems first time it's called in `arch/mips/cpu/start.S`, most likely in line 257 as I couldn't find traces of CONFIG_MIPS_INIT_STACK_IN_SRAM (besides `arch/mips/cpu/Kconfig:381` where is defined, defaults to `n` and none seems to touch anymore; second strange thing is I find no trace of it in `.config`) This, again, does not add-up (third "strange thing") because I see nothing between calls to `debug_uart_init` (start.S:257) and `board_init_f` (start.S:264) that could trigger a ~5min delay (but I'm really out of my depth, here!) unless there's something in the `printascii()`itself (e.g.: loop at serial_mtk.c:449 blocks). > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > > > U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('pinctrl at 60', 'default'): > pinctrl_select_state_full('pin_state', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full('uart2_pins', 'default'): > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > pinctrl_select_state_full('watchdog at 100', 'default'): > WDT: Started with servicing (60s timeout) > board_early_init_r(): > arch_early_init_r(): > MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): > pinctrl_select_state_full('sd_iot_mode', 'default'): > pinctrl_select_state_full('clk48m at 0', 'default'): > pinctrl_select_state_full('mmc at 10130000', 'default'): > mmc at 10130000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: uart2 at e00 > Out: uart2 at e00 > Err: uart2 at e00 > Model: VoCore2 > arch_misc_init(): > => > > Code, beside being targeted to ROM and with a different SYS_TEXT_BASE, > is identical to what runs fine when started from RAM. > > I also tried copying flash to ram: > > => cp.b bc030000 80010000 5f3c9 > => go 80010000 > ## Starting application at 0x80010000 ... > board_debug_uart_init(): > <debug_uart> [04010D08][04010D08] > DDR Calibration DQS reg = 00008888 > relocate_code Pointer at: 87f5c000 > *********************** > Watchdog Reset Occurred > *********************** > > ... but this is almost expected because I relocated at another address > without changing SYS_TEXT_BASE. > > A further measurement shows booting u-boot from flash stops for > almost 5 minutes (4m48s, using a manual stopwatch). > > I sincerely have no idea where to bang my head :( > > TiA > Mauro > > > On 1/13/20 3:14 PM, Mauro Condarelli wrote: >> Hi Stefan, >> unfortunately it does *not* work. >> >> Ram based is ok, but rom is just as silent as mine: >> >> => usb start; sf probe; >> starting USB... >> Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): >> USB EHCI 1.00 >> scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> pinctrl_select_state_full('spi at b00', 'default'): >> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total >> 16 MiB >> => load usb 0:1 85000000 u-boot_linkit.bin-rom >> 455708 bytes read in 22 ms (19.8 MiB/s) >> => sf update ${fileaddr} 0 ${filesize} >> device 0 offset 0x0, size 0x6f41c >> 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s >> => reset >> resetting ... >> pinctrl_select_state_full('syscon-reboot', 'default'): >> pinctrl_select_state_full('system-controller at 0', 'default'): >> >> I might have done something stupid; Now I need do stop, but I'll >> test again this evening. >> >> Many thanks >> Mauro >> >> >> On 1/13/20 1:45 PM, Stefan Roese wrote: >>> On 13.01.20 13:24, Mauro Condarelli wrote: >>>> On 1/13/20 12:39 PM, Stefan Roese wrote: >>>>> Hi Mauro, >>>>> >>>>> On 13.01.20 11:24, Mauro Condarelli wrote: >>>>>> On 1/13/20 7:53 AM, Stefan Roese wrote: >>>>>>> Hi Mauro, >>>>>>> >>>>>>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>>>>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>>>>>> I see. This explains of course, why your board does not boot without >>>>>>> any "preloader". >>>>>>> >>>>>>>> I wanted, nonetheless, be prepared for further mishaps, but >>>>>>>> I have some other problems (see below). >>>>>>> Are these issues now fixed? I scanned the discussion about the DEBUG >>>>>>> UART on the list. Is this working for you now or do you have any >>>>>>> other >>>>>>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >>>>>> Yes and no :( >>>>>> >>>>>> I fixed my RAM-based problems, but booting from SPI NOR still >>>>>> refuses to >>>>>> utter a single byte. >>>>>> I do attach my defconfigs and my board.c for your reading pleasure >>>>>> (in >>>>>> case you have troubles getting asleep they should provide a good >>>>>> cure). >>>>> Before looking into this in more depth (I actually do have problems >>>>> sleeping >>>>> though, so I might take a look at it later ;)), why don't you re-start >>>>> with >>>>> your defconfig by using the linkit defconfig file. If you are lucky, >>>>> the >>>>> LinkIt binary might even work for the VoCore2. Or what are the >>>>> differences >>>>> except the SoC type and WLAN? Its the same DDR2 config and the same >>>>> UART. >>>>> So it might get you pretty far - also with ROM based booting. >>>> I will try it. >>>> Just to be on the safe side, could You attach a binary (or two: ROM and >>>> RAM) to >>>> the mail? If it works it would really give me a start base. >>> See below. >>> >>>>>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >>>>>> and it >>>>>> turns out system tries to setup pins for uart2, but fails (maybe >>>>>> because >>>>>> pinctrl at 60 is not yet setup correctly?). >>>>>> This is the output I get from RAM-based u-boot: >>>>>> >>>>>> <debug_uart> board_debug_uart_init(): >>>>>> board_early_init_f(): >>>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >>>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>>> >>>>>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>>>>> >>>>>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>>>>> Model: VoCore2 >>>>>> DRAM: 128 MiB >>>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>>> pinctrl_select_state_full('pinctrl at 60', 'default'): >>>>>> pinctrl_select_state_full('pin_state', 'default'): >>>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>>> pinctrl_select_state_full('uart2_pins', 'default'): >>>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>>> pinctrl_select_state_full('watchdog at 100', 'default'): >>>>>> WDT: Started with servicing (60s timeout) >>>>>> board_early_init_r(): >>>>>> arch_early_init_r(): >>>>>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>>> pinctrl_select_state_full('sd_iot_mode', 'default'): >>>>>> pinctrl_select_state_full('clk48m at 0', 'default'): >>>>>> pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>>> mmc at 10130000: 0 >>>>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>>>> environment >>>>>> >>>>>> In: uart2 at e00 >>>>>> Out: uart2 at e00 >>>>>> Err: uart2 at e00 >>>>>> Model: VoCore2 >>>>>> arch_misc_init(): >>>>>> => >>>>> I don't have all these pinctrl issues on LinkIt. I suspect a config >>>>> issue and / or dts issue. Please compare. >>>> I will, but I was trying to say something different: >>>> Apparently the stock software tries to initialize uart2 pinctrl and it >>>> *seems* to succeed later in initialization. >>>> This *seems* to indicate explicit pin setup in board_early_init_f() is >>>> not strictly needed (we would lose only the first few lines even if >>>> we don't fix the error). >>>> I had a look to pinctrl-mt7628.c and it seems to do the right thing >>>> upon call to ('uart2_pins', 'default'), so anything after that *should* >>>> work even without low-level setup. >>> You might be correct here. So this explicit pin-muxing for UART2 is >>> only needed when DEBUG UART is used. This makes the code a bit clearer >>> and smaller. Lets keep it on our list to remove this, once all this >>> is resolved. >>> >>>>>> ROM-based u-boot, as said, does not print *anything*, not even >>>>>> garbage. >>>>>> I'm beginning to suspect I have some mishap with start address or >>>>>> similar. >>>>>> I have absolutely no idea how to debug this without a JTAG probe >>>>>> (which >>>>>> I don't have and would be non-trivial to get working; soldering >>>>>> required). >>>>> Yes. JTAG requires soldering IIRC. >>>>> >>>>>> The only idea I currently have is to modify my "old" u-boot to do >>>>>> initialization >>>>>> and then jump to beginning of "new" u-boot. >>>>>> If I can make it work in an automatic way I can try removing >>>>>> initialization steps >>>>>> till I find the "culprit". >>>>>> Any better idea would be welcome, of course! >>>>>> >>>>>> If I have to resort to that clumsy method, would be enough to put >>>>>> "new" >>>>>> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >>>>>> only >>>>>> 183272 bytes long) and jump to the first location? >>>>>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 >>>>> This is the TEXT_BASE for ROM based booting: >>>>> >>>>> CONFIG_SYS_TEXT_BASE=0x9c000000 >>>> AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory >>>> region, the latter being uncached. >>>> I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some >>>> space for "old" (possibly crippled) u-boot doing initialization and then >>>> "jumping" >>>> to "new". >>> I see. Please give the LinkIt version a try first. This sounds easier >>> (if it works) and more promising for my taste. >>> >>>>> Please see configs/linkit-smart-7688_defconfig. >>>>> >>>>>> Did I forget something? >>>>> Not sure. I still think using the linkit port as a base for SPI NOR >>>>> based booting would be a very good test at least. Do you see any >>>>> problems with this approach (board / SoC differences)? >>>> No. I see no troubles, for a basic startup. >>>> MMC would probably need some changes, but that can come later. >>> Yes. This test is just for basic very low level bootup checking. If >>> this works, then you can use it as a basis to fine-tune your VoCore2 >>> version from it by changing MMC etc support. >>> >>>> As said: I would like to try a prebuilt binary as first thing, so I can >>>> be sure I have no other problems (like gcc version or other local >>>> variations); then I would try to reproduce locally the equivalent binary >>>> with no changes and finally I would try to incorporate my specific >>>> needs. >>>> What do You think? >>> Please find attached the current mainline versions for LinkIt, one >>> for RAM booting and one for ROM booting (in SPI NOR). I checked both >>> version and they work fine on my LinkIt 7688 board: >>> >>> U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100) >>> >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) >>> Model: LinkIt-Smart-7688 >>> DRAM: 128 MiB >>> Loading Environment from SPI Flash... SF: Detected mx25l25635e with >>> page size 256 Bytes, erase size 64 KiB, total 32 MiB >>> OK >>> Net: eth0: eth at 10110000 >>> Hit any key to stop autoboot: 0 >>> => >>> >>> >>> Thanks, >>> Stefan Regards Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup (was: How to debug HW startup?) 2020-01-13 23:08 ` Mauro Condarelli 2020-01-14 11:03 ` Mauro Condarelli @ 2020-01-14 23:55 ` Mauro Condarelli 2020-01-15 7:25 ` Debugging VoCore2 ROM Startup Stefan Roese 1 sibling, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-14 23:55 UTC (permalink / raw) To: u-boot I found *one* of the bugs in startup: To enable UART2 pinmux setting: void __iomem *gpio_mode; gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100); clrbits_le32(gpio_mode, GENMASK(27, 26)); is not enough; you need also: setbits_le32(gpio_mode, GENMASK(3, 2)); I actually use the more explicit, but hopefully equivalent: #define MT76XX_GPIO1_MODE 0x10000060 #define MIPS_KSEG1_START 0xA0000000 uint32_t v, *a; a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); v = *a; v &= 0xF3FFFFFF; v |= 0x0000000C; *a = v; It is unclear to me how Linkit port could work. Anyways now my "secondary from ROM" approach now works without the long delay described below. Unfortunately this does not seem to be the whole story because flashing u-boot linked directly in the "right palace": SYS_TEXT_BASE = 0x9c000000 still refuses to display anything on serial; I assume some other initialization is missing, but that will be another fight. Any insight welcome. Regards Mauro On 1/14/20 12:08 AM, Mauro Condarelli wrote: > Next episode of this telenovela: > > I rebuilt u-boot for ROM at BC030000 (my code, very similar to LinkIt). > I flashed it at 30000 in SPI NOR: > > => usb start; sf probe > starting USB... > Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): > USB EHCI 1.00 > scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total > 16 MiB > => load usb 0:1 85000000 u-boot.secondary > 390089 bytes read in 18 ms (20.7 MiB/s) > => sf update ${fileaddr} 30000 ${filesize} > device 0 offset 0x30000, size 0x5f3c9 > 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s > => reset > > Restarted old u-boot and jumped to new: > > U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) > VoCore2 > go bc030000 > ## Starting application at 0xBC030000 ... > board_debug_uart_init(): > <debug_uart> > System stopped here several minutes, enough for me to start writing > this email, then it continued boot sequence: > board_debug_uart_init(): > board_early_init_f(): > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > > > U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > pinctrl_select_state_full('palmbus at 10000000', 'default'): > pinctrl_select_state_full('pinctrl at 60', 'default'): > pinctrl_select_state_full('pin_state', 'default'): > pinctrl_select_state_full('uart2 at e00', 'default'): > pinctrl_select_state_full('uart2_pins', 'default'): > pinctrl_select_state_full('clkctrl at 0x2c', 'default'): > pinctrl_select_state_full('watchdog at 100', 'default'): > WDT: Started with servicing (60s timeout) > board_early_init_r(): > arch_early_init_r(): > MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): > pinctrl_select_state_full('sd_iot_mode', 'default'): > pinctrl_select_state_full('clk48m at 0', 'default'): > pinctrl_select_state_full('mmc at 10130000', 'default'): > mmc at 10130000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: uart2 at e00 > Out: uart2 at e00 > Err: uart2 at e00 > Model: VoCore2 > arch_misc_init(): > => > > Code, beside being targeted to ROM and with a different SYS_TEXT_BASE, > is identical to what runs fine when started from RAM. > > I also tried copying flash to ram: > > => cp.b bc030000 80010000 5f3c9 > => go 80010000 > ## Starting application at 0x80010000 ... > board_debug_uart_init(): > <debug_uart> [04010D08][04010D08] > DDR Calibration DQS reg = 00008888 > relocate_code Pointer at: 87f5c000 > *********************** > Watchdog Reset Occurred > *********************** > > ... but this is almost expected because I relocated at another address > without changing SYS_TEXT_BASE. > > A further measurement shows booting u-boot from flash stops for > almost 5 minutes (4m48s, using a manual stopwatch). > > I sincerely have no idea where to bang my head :( > > TiA > Mauro > > > On 1/13/20 3:14 PM, Mauro Condarelli wrote: >> Hi Stefan, >> unfortunately it does *not* work. >> >> Ram based is ok, but rom is just as silent as mine: >> >> => usb start; sf probe; >> starting USB... >> Bus ehci at 101c0000: pinctrl_select_state_full('ehci at 101c0000', 'default'): >> USB EHCI 1.00 >> scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> pinctrl_select_state_full('spi at b00', 'default'): >> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total >> 16 MiB >> => load usb 0:1 85000000 u-boot_linkit.bin-rom >> 455708 bytes read in 22 ms (19.8 MiB/s) >> => sf update ${fileaddr} 0 ${filesize} >> device 0 offset 0x0, size 0x6f41c >> 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s >> => reset >> resetting ... >> pinctrl_select_state_full('syscon-reboot', 'default'): >> pinctrl_select_state_full('system-controller at 0', 'default'): >> >> I might have done something stupid; Now I need do stop, but I'll >> test again this evening. >> >> Many thanks >> Mauro >> >> >> On 1/13/20 1:45 PM, Stefan Roese wrote: >>> On 13.01.20 13:24, Mauro Condarelli wrote: >>>> On 1/13/20 12:39 PM, Stefan Roese wrote: >>>>> Hi Mauro, >>>>> >>>>> On 13.01.20 11:24, Mauro Condarelli wrote: >>>>>> On 1/13/20 7:53 AM, Stefan Roese wrote: >>>>>>> Hi Mauro, >>>>>>> >>>>>>> On 11.01.20 20:00, Mauro Condarelli wrote: >>>>>>>> I managed to find ONE of the reasons why my ROM build didn't run: >>>>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. >>>>>>> I see. This explains of course, why your board does not boot without >>>>>>> any "preloader". >>>>>>> >>>>>>>> I wanted, nonetheless, be prepared for further mishaps, but >>>>>>>> I have some other problems (see below). >>>>>>> Are these issues now fixed? I scanned the discussion about the DEBUG >>>>>>> UART on the list. Is this working for you now or do you have any >>>>>>> other >>>>>>> issues still? Did you successfully boot your new U-Boot from SPI NOR? >>>>>> Yes and no :( >>>>>> >>>>>> I fixed my RAM-based problems, but booting from SPI NOR still >>>>>> refuses to >>>>>> utter a single byte. >>>>>> I do attach my defconfigs and my board.c for your reading pleasure >>>>>> (in >>>>>> case you have troubles getting asleep they should provide a good >>>>>> cure). >>>>> Before looking into this in more depth (I actually do have problems >>>>> sleeping >>>>> though, so I might take a look at it later ;)), why don't you re-start >>>>> with >>>>> your defconfig by using the linkit defconfig file. If you are lucky, >>>>> the >>>>> LinkIt binary might even work for the VoCore2. Or what are the >>>>> differences >>>>> except the SoC type and WLAN? Its the same DDR2 config and the same >>>>> UART. >>>>> So it might get you pretty far - also with ROM based booting. >>>> I will try it. >>>> Just to be on the safe side, could You attach a binary (or two: ROM and >>>> RAM) to >>>> the mail? If it works it would really give me a start base. >>> See below. >>> >>>>>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c >>>>>> and it >>>>>> turns out system tries to setup pins for uart2, but fails (maybe >>>>>> because >>>>>> pinctrl at 60 is not yet setup correctly?). >>>>>> This is the output I get from RAM-based u-boot: >>>>>> >>>>>> <debug_uart> board_debug_uart_init(): >>>>>> board_early_init_f(): >>>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 >>>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>>> >>>>>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>>>>> >>>>>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>>>>> Model: VoCore2 >>>>>> DRAM: 128 MiB >>>>>> pinctrl_select_state_full('palmbus at 10000000', 'default'): >>>>>> pinctrl_select_state_full('pinctrl at 60', 'default'): >>>>>> pinctrl_select_state_full('pin_state', 'default'): >>>>>> pinctrl_select_state_full('uart2 at e00', 'default'): >>>>>> pinctrl_select_state_full('uart2_pins', 'default'): >>>>>> pinctrl_select_state_full('clkctrl at 0x2c', 'default'): >>>>>> pinctrl_select_state_full('watchdog at 100', 'default'): >>>>>> WDT: Started with servicing (60s timeout) >>>>>> board_early_init_r(): >>>>>> arch_early_init_r(): >>>>>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>>> pinctrl_select_state_full('sd_iot_mode', 'default'): >>>>>> pinctrl_select_state_full('clk48m at 0', 'default'): >>>>>> pinctrl_select_state_full('mmc at 10130000', 'default'): >>>>>> mmc at 10130000: 0 >>>>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>>>> environment >>>>>> >>>>>> In: uart2 at e00 >>>>>> Out: uart2 at e00 >>>>>> Err: uart2 at e00 >>>>>> Model: VoCore2 >>>>>> arch_misc_init(): >>>>>> => >>>>> I don't have all these pinctrl issues on LinkIt. I suspect a config >>>>> issue and / or dts issue. Please compare. >>>> I will, but I was trying to say something different: >>>> Apparently the stock software tries to initialize uart2 pinctrl and it >>>> *seems* to succeed later in initialization. >>>> This *seems* to indicate explicit pin setup in board_early_init_f() is >>>> not strictly needed (we would lose only the first few lines even if >>>> we don't fix the error). >>>> I had a look to pinctrl-mt7628.c and it seems to do the right thing >>>> upon call to ('uart2_pins', 'default'), so anything after that *should* >>>> work even without low-level setup. >>> You might be correct here. So this explicit pin-muxing for UART2 is >>> only needed when DEBUG UART is used. This makes the code a bit clearer >>> and smaller. Lets keep it on our list to remove this, once all this >>> is resolved. >>> >>>>>> ROM-based u-boot, as said, does not print *anything*, not even >>>>>> garbage. >>>>>> I'm beginning to suspect I have some mishap with start address or >>>>>> similar. >>>>>> I have absolutely no idea how to debug this without a JTAG probe >>>>>> (which >>>>>> I don't have and would be non-trivial to get working; soldering >>>>>> required). >>>>> Yes. JTAG requires soldering IIRC. >>>>> >>>>>> The only idea I currently have is to modify my "old" u-boot to do >>>>>> initialization >>>>>> and then jump to beginning of "new" u-boot. >>>>>> If I can make it work in an automatic way I can try removing >>>>>> initialization steps >>>>>> till I find the "culprit". >>>>>> Any better idea would be welcome, of course! >>>>>> >>>>>> If I have to resort to that clumsy method, would be enough to put >>>>>> "new" >>>>>> in SPI NOR (of course at an higher address, e.g.: 30000 as "old" is >>>>>> only >>>>>> 183272 bytes long) and jump to the first location? >>>>>> I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 >>>>> This is the TEXT_BASE for ROM based booting: >>>>> >>>>> CONFIG_SYS_TEXT_BASE=0x9c000000 >>>> AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory >>>> region, the latter being uncached. >>>> I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some >>>> space for "old" (possibly crippled) u-boot doing initialization and then >>>> "jumping" >>>> to "new". >>> I see. Please give the LinkIt version a try first. This sounds easier >>> (if it works) and more promising for my taste. >>> >>>>> Please see configs/linkit-smart-7688_defconfig. >>>>> >>>>>> Did I forget something? >>>>> Not sure. I still think using the linkit port as a base for SPI NOR >>>>> based booting would be a very good test at least. Do you see any >>>>> problems with this approach (board / SoC differences)? >>>> No. I see no troubles, for a basic startup. >>>> MMC would probably need some changes, but that can come later. >>> Yes. This test is just for basic very low level bootup checking. If >>> this works, then you can use it as a basis to fine-tune your VoCore2 >>> version from it by changing MMC etc support. >>> >>>> As said: I would like to try a prebuilt binary as first thing, so I can >>>> be sure I have no other problems (like gcc version or other local >>>> variations); then I would try to reproduce locally the equivalent binary >>>> with no changes and finally I would try to incorporate my specific >>>> needs. >>>> What do You think? >>> Please find attached the current mainline versions for LinkIt, one >>> for RAM booting and one for ROM booting (in SPI NOR). I checked both >>> version and they work fine on my LinkIt 7688 board: >>> >>> U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100) >>> >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) >>> Model: LinkIt-Smart-7688 >>> DRAM: 128 MiB >>> Loading Environment from SPI Flash... SF: Detected mx25l25635e with >>> page size 256 Bytes, erase size 64 KiB, total 32 MiB >>> OK >>> Net: eth0: eth at 10110000 >>> Hit any key to stop autoboot: 0 >>> => >>> >>> >>> Thanks, >>> Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-14 23:55 ` Debugging VoCore2 ROM Startup (was: How to debug HW startup?) Mauro Condarelli @ 2020-01-15 7:25 ` Stefan Roese 2020-01-15 9:04 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-15 7:25 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 00:55, Mauro Condarelli wrote: > I found *one* of the bugs in startup: > To enable UART2 pinmux setting: > void __iomem *gpio_mode; > gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100); > clrbits_le32(gpio_mode, GENMASK(27, 26)); > is not enough; you need also: > setbits_le32(gpio_mode, GENMASK(3, 2)); > I actually use the more explicit, but hopefully equivalent: > #define MT76XX_GPIO1_MODE 0x10000060 > #define MIPS_KSEG1_START 0xA0000000 > > uint32_t v, *a; > a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); > v = *a; > v &= 0xF3FFFFFF; > v |= 0x0000000C; > *a = v; > > It is unclear to me how Linkit port could work. I double checked on LiniIt and it works without this bit 2/3 setting: => md b0000060 1 b0000060: 50050404 ...P You can check this on your VoCore2 board by setting this value from the prompt. If this works, then its not strictly needed. > Anyways now my "secondary from ROM" approach now > works without the long delay described below. > > Unfortunately this does not seem to be the whole story because > flashing u-boot linked directly in the "right palace": > > SYS_TEXT_BASE = 0x9c000000 > > still refuses to display anything on serial; I assume some other > initialization is missing, but that will be another fight. > > Any insight welcome. Did my new image from yesterday produce any output on your board? BTW: How do you flash the image into SPI NOR? From the new mainline U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps something is going wrong in the flashing process? Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 7:25 ` Debugging VoCore2 ROM Startup Stefan Roese @ 2020-01-15 9:04 ` Mauro Condarelli 2020-01-15 9:31 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-15 9:04 UTC (permalink / raw) To: u-boot HI Stefan, On 1/15/20 8:25 AM, Stefan Roese wrote: > Hi Mauro, > > On 15.01.20 00:55, Mauro Condarelli wrote: >> I found *one* of the bugs in startup: >> To enable UART2 pinmux setting: >> void __iomem *gpio_mode; >> gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100); >> clrbits_le32(gpio_mode, GENMASK(27, 26)); >> is not enough; you need also: >> setbits_le32(gpio_mode, GENMASK(3, 2)); >> I actually use the more explicit, but hopefully equivalent: >> #define MT76XX_GPIO1_MODE 0x10000060 >> #define MIPS_KSEG1_START 0xA0000000 >> >> uint32_t v, *a; >> a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); >> v = *a; >> v &= 0xF3FFFFFF; >> v |= 0x0000000C; >> *a = v; >> >> It is unclear to me how Linkit port could work. > > I double checked on LiniIt and it works without this bit 2/3 > setting: > > => md b0000060 1 > b0000060: 50050404 ...P > > You can check this on your VoCore2 board by setting this value > from the prompt. If this works, then its not strictly needed. > This seems to be strictly needed on my board: U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) VoCore2 > md b0000060 1 b0000060: 5505040c ...U VoCore2 > mm b0000060 b0000060: 5505040c ? 55050404 <DEAD> This is with the original "paleolithic" u-boot, of course, but it should be a HW-related feature, should I try also with "current" (RAM based)? I am surprised though as all I could find on differences between MT7628 and MT7688 are is a reference on Mediatek site: https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq Q: What’s MT7628 and how is it different from MT7688AN? The MT7628 series are pin-to-pin compatible with the MT7688 series. However, MT7628 comes with a 2T2R antenna, while MT7688 only supports 1T1R antenna. (Incomplete!) comparison of the two datasheets did not show relevant differences. >> Anyways now my "secondary from ROM" approach now >> works without the long delay described below. >> >> Unfortunately this does not seem to be the whole story because >> flashing u-boot linked directly in the "right palace": >> >> SYS_TEXT_BASE = 0x9c000000 >> >> still refuses to display anything on serial; I assume some other >> initialization is missing, but that will be another fight. >> >> Any insight welcome. > > Did my new image from yesterday produce any output on your board? No. Your image was as silent as mine. Not a single char in serial line. > BTW: How do you flash the image into SPI NOR? From the new mainline > U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps > something is going wrong in the flashing process? I will try to read back after flashing, but I somewhat doubt that's the problem. I am using the new, RAM-based U-Boot to flash. Actual sequence is: usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 usb start; sf probe; load usb 0:1 85000000 u-boot-rom.bin; sf update ${fileaddr} u-boot ${filesize} reset where: => mtd list List of MTD devices: * nor0 - type: NOR flash - block size: 0x1000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000001000000 : "nor0" - 0x000000000000-0x00000007e000 : "u-boot" - 0x00000007e000-0x00000007f000 : "env" - 0x00000007f000-0x000000080000 : "factory" - 0x000000080000-0x000000320000 : "kernel" - 0x000000320000-0x000001000000 : "filesystem" Equivalent sequences work correctly to flash kernel and (recovery) filesystem. > Thanks, > Stefan Many thanks for Your patience... Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 9:04 ` Mauro Condarelli @ 2020-01-15 9:31 ` Stefan Roese 2020-01-15 9:51 ` Stefan Roese 2020-01-15 10:23 ` Mauro Condarelli 0 siblings, 2 replies; 30+ messages in thread From: Stefan Roese @ 2020-01-15 9:31 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 10:04, Mauro Condarelli wrote: >> On 15.01.20 00:55, Mauro Condarelli wrote: >>> I found *one* of the bugs in startup: >>> To enable UART2 pinmux setting: >>> void __iomem *gpio_mode; >>> gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100); >>> clrbits_le32(gpio_mode, GENMASK(27, 26)); >>> is not enough; you need also: >>> setbits_le32(gpio_mode, GENMASK(3, 2)); >>> I actually use the more explicit, but hopefully equivalent: >>> #define MT76XX_GPIO1_MODE 0x10000060 >>> #define MIPS_KSEG1_START 0xA0000000 >>> >>> uint32_t v, *a; >>> a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); >>> v = *a; >>> v &= 0xF3FFFFFF; >>> v |= 0x0000000C; >>> *a = v; >>> >>> It is unclear to me how Linkit port could work. >> >> I double checked on LiniIt and it works without this bit 2/3 >> setting: >> >> => md b0000060 1 >> b0000060: 50050404 ...P >> >> You can check this on your VoCore2 board by setting this value >> from the prompt. If this works, then its not strictly needed. >> > This seems to be strictly needed on my board: > U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) > VoCore2 > md b0000060 1 > b0000060: 5505040c ...U > VoCore2 > mm b0000060 > b0000060: 5505040c ? 55050404 > <DEAD> > This is with the original "paleolithic" u-boot, of course, but it > should be a HW-related feature, should I try also with "current" > (RAM based)? In your version above, you do *not* have configured bits 27:26 (UART2 GPIO mode) to 00b but to 01b (GPIO mode). I did this test on my LinkIt and wrote your original value: => mw b0000060 5505040c� <DEAD> So this does not work for me. You might want to try my value "50050404" with your 1.1.3 version to see, if this works there. But I dount it. > I am surprised though as all I could find on differences between > MT7628 and MT7688 are is a reference on Mediatek site: > https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq > > Q: What’s MT7628 and how is it different from MT7688AN? > > The MT7628 series are pin-to-pin compatible with the MT7688 series. > However, MT7628 comes with a 2T2R antenna, while MT7688 only supports > 1T1R antenna. > > (Incomplete!) comparison of the two datasheets did not show > relevant differences. >>> Anyways now my "secondary from ROM" approach now >>> works without the long delay described below. >>> >>> Unfortunately this does not seem to be the whole story because >>> flashing u-boot linked directly in the "right palace": >>> >>> SYS_TEXT_BASE = 0x9c000000 >>> >>> still refuses to display anything on serial; I assume some other >>> initialization is missing, but that will be another fight. >>> >>> Any insight welcome. >> >> Did my new image from yesterday produce any output on your board? > No. > Your image was as silent as mine. > Not a single char in serial line. I see. If you really need a different UART2 mux setup in the GPIO1_MODE register, this might explain the difference. I can generate a new image (untested) with your GPIO1_MODE value of 5505040c for you to test. Just let me know. >> BTW: How do you flash the image into SPI NOR? From the new mainline >> U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps >> something is going wrong in the flashing process? > I will try to read back after flashing, but I somewhat doubt that's the > problem. Yes, please do. > I am using the new, RAM-based U-Boot to flash. > Actual sequence is: > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 > usb start; sf probe; > load usb 0:1 85000000 u-boot-rom.bin; sf update ${fileaddr} u-boot > ${filesize} > reset > where: > => mtd list > List of MTD devices: > * nor0 > - type: NOR flash > - block size: 0x1000 bytes > - min I/O: 0x1 bytes > - 0x000000000000-0x000001000000 : "nor0" > - 0x000000000000-0x00000007e000 : "u-boot" > - 0x00000007e000-0x00000007f000 : "env" > - 0x00000007f000-0x000000080000 : "factory" > - 0x000000080000-0x000000320000 : "kernel" > - 0x000000320000-0x000001000000 : "filesystem" > Equivalent sequences work correctly to flash kernel and (recovery) > filesystem. Looks correct at first glance. Here my sequence: => printenv upd_uboot load_uboot update_uboot upd_uboot=run load_uboot update_uboot load_uboot=tftp ${loadaddr} ${tftpdir}/u-boot.bin update_uboot=sf probe;sf update ${loadaddr} 0 ${filesize} Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 9:31 ` Stefan Roese @ 2020-01-15 9:51 ` Stefan Roese 2020-01-15 10:23 ` Mauro Condarelli 1 sibling, 0 replies; 30+ messages in thread From: Stefan Roese @ 2020-01-15 9:51 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 10:31, Stefan Roese wrote: <snip> >>>> still refuses to display anything on serial; I assume some other >>>> initialization is missing, but that will be another fight. >>>> >>>> Any insight welcome. One further idea: Lets give the image with the new SPL support from Weijie a try. Please find the ROM image attached. Here the lowlevel code is different so this might prove helpful on this SoC. Thanks, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: u-boot-mtmips.bin Type: application/octet-stream Size: 465744 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200115/5ccbdbe5/attachment-0001.bin> ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 9:31 ` Stefan Roese 2020-01-15 9:51 ` Stefan Roese @ 2020-01-15 10:23 ` Mauro Condarelli 2020-01-15 10:48 ` Stefan Roese 1 sibling, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-15 10:23 UTC (permalink / raw) To: u-boot Hi Stefan, On 1/15/20 10:31 AM, Stefan Roese wrote: > Hi Mauro, > > On 15.01.20 10:04, Mauro Condarelli wrote: >>> On 15.01.20 00:55, Mauro Condarelli wrote: >>>> I found *one* of the bugs in startup: >>>> To enable UART2 pinmux setting: >>>> void __iomem *gpio_mode; >>>> gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100); >>>> clrbits_le32(gpio_mode, GENMASK(27, 26)); >>>> is not enough; you need also: >>>> setbits_le32(gpio_mode, GENMASK(3, 2)); >>>> I actually use the more explicit, but hopefully equivalent: >>>> #define MT76XX_GPIO1_MODE 0x10000060 >>>> #define MIPS_KSEG1_START 0xA0000000 >>>> >>>> uint32_t v, *a; >>>> a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); >>>> v = *a; >>>> v &= 0xF3FFFFFF; >>>> v |= 0x0000000C; >>>> *a = v; >>>> >>>> It is unclear to me how Linkit port could work. >>> >>> I double checked on LiniIt and it works without this bit 2/3 >>> setting: >>> >>> => md b0000060 1 >>> b0000060: 50050404 ...P >>> >>> You can check this on your VoCore2 board by setting this value >>> from the prompt. If this works, then its not strictly needed. >>> >> This seems to be strictly needed on my board: >> U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) >> VoCore2 > md b0000060 1 >> b0000060: 5505040c ...U >> VoCore2 > mm b0000060 >> b0000060: 5505040c ? 55050404 >> <DEAD> >> This is with the original "paleolithic" u-boot, of course, but it >> should be a HW-related feature, should I try also with "current" >> (RAM based)? > > In your version above, you do *not* have configured bits 27:26 > (UART2 GPIO mode) to 00b but to 01b (GPIO mode). > > I did this test on my LinkIt and wrote your original value: > > => mw b0000060 5505040c� > <DEAD> > > So this does not work for me. > > You might want to try my value "50050404" with your 1.1.3 version > to see, if this works there. But I dount it. As expected it does NOT work. > >> I am surprised though as all I could find on differences between >> MT7628 and MT7688 are is a reference on Mediatek site: >> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq >> >> Q: What’s MT7628 and how is it different from MT7688AN? >> >> The MT7628 series are pin-to-pin compatible with the MT7688 series. >> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports >> 1T1R antenna. >> >> (Incomplete!) comparison of the two datasheets did not show >> relevant differences. I have started an analysis of current register status (and I quickly hit limitation of the documentation I have): b0000008: 00010000 .... E-Fuse Configuration is not pristine, but I don't know what it my mean. b0000010: 00111144 D... System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 1000 1000 00000000 TEST_CODE 000 * 100010001 BS_SHADOW 000 * 1 DBG_JTAG_MODE 1: Normal Boot-up 1 TEST_MODE_1 ?? 0 XTAL_FREQ_SEL 0: 25MHz DIP ??? 0 EXT_BG 0: BG clock from PMU 0 TEST_MODE_0 0: SUTIF 100 CHIP_MODE 100: SCAN mode 0 DRAM_TYPE 0: DDR2 I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might signal a different up/down pulling of Bootstrapping Pins. Could You cross check on LinkIt, please? >>>> Anyways now my "secondary from ROM" approach now >>>> works without the long delay described below. >>>> >>>> Unfortunately this does not seem to be the whole story because >>>> flashing u-boot linked directly in the "right palace": >>>> >>>> SYS_TEXT_BASE = 0x9c000000 >>>> >>>> still refuses to display anything on serial; I assume some other >>>> initialization is missing, but that will be another fight. >>>> >>>> Any insight welcome. >>> >>> Did my new image from yesterday produce any output on your board? >> No. >> Your image was as silent as mine. >> Not a single char in serial line. > > I see. If you really need a different UART2 mux setup in the GPIO1_MODE > register, this might explain the difference. I can generate a new image > (untested) with your GPIO1_MODE value of 5505040c for you to test. Just > let me know. Before doing that we should check boot status (and pins). >>> BTW: How do you flash the image into SPI NOR? From the new mainline >>> U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps >>> something is going wrong in the flashing process? >> I will try to read back after flashing, but I somewhat doubt that's the >> problem. > > Yes, please do. I will do on next (potentially destructive) iteration ;) I will also suspend your other suggestion (Weijie code) till we make sure boot sequence is compatible. >> I am using the new, RAM-based U-Boot to flash. >> Actual sequence is: >> usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 >> usb start; sf probe; >> load usb 0:1 85000000 u-boot-rom.bin; sf update ${fileaddr} u-boot >> ${filesize} >> reset >> where: >> => mtd list >> List of MTD devices: >> * nor0 >> - type: NOR flash >> - block size: 0x1000 bytes >> - min I/O: 0x1 bytes >> - 0x000000000000-0x000001000000 : "nor0" >> - 0x000000000000-0x00000007e000 : "u-boot" >> - 0x00000007e000-0x00000007f000 : "env" >> - 0x00000007f000-0x000000080000 : "factory" >> - 0x000000080000-0x000000320000 : "kernel" >> - 0x000000320000-0x000001000000 : "filesystem" >> Equivalent sequences work correctly to flash kernel and (recovery) >> filesystem. > > Looks correct at first glance. Here my sequence: > > => printenv upd_uboot load_uboot update_uboot > upd_uboot=run load_uboot update_uboot > load_uboot=tftp ${loadaddr} ${tftpdir}/u-boot.bin > update_uboot=sf probe;sf update ${loadaddr} 0 ${filesize} Understood. > > Thanks, > Stefan Many Thanks Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 10:23 ` Mauro Condarelli @ 2020-01-15 10:48 ` Stefan Roese 2020-01-15 12:50 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-15 10:48 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 11:23, Mauro Condarelli wrote: >>> I am surprised though as all I could find on differences between >>> MT7628 and MT7688 are is a reference on Mediatek site: >>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq >>> >>> Q: What’s MT7628 and how is it different from MT7688AN? >>> >>> The MT7628 series are pin-to-pin compatible with the MT7688 series. >>> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports >>> 1T1R antenna. >>> >>> (Incomplete!) comparison of the two datasheets did not show >>> relevant differences. > I have started an analysis of current register status (and I quickly hit > limitation of the documentation I have): > > b0000008: 00010000 .... > E-Fuse Configuration is not pristine, but I don't know what it my mean. > > b0000010: 00111144 D... > System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 1000 1000 Not correct: System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 0100 0100 > > 00000000 TEST_CODE > 000 * > 100010001 BS_SHADOW > 000 * > 1 DBG_JTAG_MODE 1: Normal Boot-up > 1 TEST_MODE_1 ?? > 0 XTAL_FREQ_SEL 0: 25MHz DIP ??? > 0 EXT_BG 0: BG clock from PMU > 0 TEST_MODE_0 0: SUTIF > 100 CHIP_MODE 100: SCAN mode Not correct. You have here 010, so XTAL with 3-byte ADR > 0 DRAM_TYPE 0: DDR2 > > I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might > signal a different up/down pulling of Bootstrapping Pins. > Could You cross check on LinkIt, please? => md b0000000 b0000000: 3637544d 20203832 00100000 00010102 MT7628 ........ b0000010: 00156156 02605500 00000000 00000000 Va...U`......... b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . b0000030: ffffffc0 04000000 c0030004 00fe00ff ................ b0000040: 00000000 0001ffff 00000000 00000000 ................ b0000050: 00000000 00000000 00000000 00000810 ................ b0000060: 50050404 05550551 00000000 00000000 ...PQ.U......... SYSCFG0: 00156156 CHIP_MODE: 011: XTAL with 4-byte ADR. Mainline U-Boot reports this: CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) and the new code from Weijie reports this: CPU: MediaTek MT7688A ver:1 eco:2 Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz One important difference which might explain a lot, it XTAL_FREQ_SEL which is 0 in your case and 1 in my case. IIUTC, then the new code from Weijie takes this XTAL selection into account. Weijie might comment on this. I suggest that you give this "u-boot-mtmips.bin" binary a try. Good luck. :) Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 10:48 ` Stefan Roese @ 2020-01-15 12:50 ` Mauro Condarelli 2020-01-15 15:04 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-15 12:50 UTC (permalink / raw) To: u-boot Hi Stefan, On 1/15/20 11:48 AM, Stefan Roese wrote: > Hi Mauro, > > On 15.01.20 11:23, Mauro Condarelli wrote: >>>> I am surprised though as all I could find on differences between >>>> MT7628 and MT7688 are is a reference on Mediatek site: >>>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq >>>> >>>> Q: What’s MT7628 and how is it different from MT7688AN? >>>> >>>> The MT7628 series are pin-to-pin compatible with the MT7688 series. >>>> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports >>>> 1T1R antenna. >>>> >>>> (Incomplete!) comparison of the two datasheets did not show >>>> relevant differences. >> I have started an analysis of current register status (and I quickly hit >> limitation of the documentation I have): >> >> b0000008: 00010000 .... >> E-Fuse Configuration is not pristine, but I don't know what it my mean. >> >> b0000010: 00111144 D... >> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 1000 >> 1000 > > Not correct: > > System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 0100 0100 Right. Shame on me. >> 00000000 TEST_CODE >> 000 * >> 100010001 BS_SHADOW >> 000 * >> 1 DBG_JTAG_MODE 1: Normal Boot-up >> 1 TEST_MODE_1 ?? >> 0 XTAL_FREQ_SEL 0: 25MHz DIP ??? >> 0 EXT_BG 0: BG clock from PMU >> 0 TEST_MODE_0 0: SUTIF >> 100 CHIP_MODE 100: SCAN mode > > Not correct. You have here 010, so XTAL with 3-byte ADR > >> 0 DRAM_TYPE 0: DDR2 >> >> I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might >> signal a different up/down pulling of Bootstrapping Pins. >> Could You cross check on LinkIt, please? > > => md b0000000 > b0000000: 3637544d 20203832 00100000 00010102 MT7628 ........ > b0000010: 00156156 02605500 00000000 00000000 Va...U`......... > b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . > b0000030: ffffffc0 04000000 c0030004 00fe00ff ................ > b0000040: 00000000 0001ffff 00000000 00000000 ................ > b0000050: 00000000 00000000 00000000 00000810 ................ > b0000060: 50050404 05550551 00000000 00000000 ...PQ.U......... This is my register dump, for reference: VoCore2 > md b0000000 b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ b0000010: 00144144 02605500 00000000 00000000 DA...U`......... b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... b0000040: 00000000 0001ffff 00000000 00000000 ................ b0000050: 00000000 00000000 00000000 00000810 ................ b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... > > SYSCFG0: 00156156 > > CHIP_MODE: 011: XTAL with 4-byte ADR. > > Mainline U-Boot reports this: > > CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) My mainline (RAM) reports: CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > > and the new code from Weijie reports this: > > CPU: MediaTek MT7688A ver:1 eco:2 > Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL > Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz > > One important difference which might explain a lot, it XTAL_FREQ_SEL > which is 0 in your case and 1 in my case. > > IIUTC, then the new code from Weijie takes this XTAL selection > into account. Weijie might comment on this. I suggest that you give > this "u-boot-mtmips.bin" binary a try. Good luck. :) No good ;( Here's transcript: VoCore2 > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 (Re)start USB... USB0: Mediatek/Ralink USB EHCI Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found reading u-boot-ram.bin ........................................................................... 387097 bytes read ## Starting application at 0x80010000 ... <debug_uart> board_debug_uart_init(): board_early_init_f(): U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) Model: VoCore2 DRAM: 128 MiB WDT: Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): mmc at 10130000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: uart2 at e00 Out: uart2 at e00 Err: uart2 at e00 Model: VoCore2 arch_misc_init(): => usb start; load usb 0:1 85000000 u-boot-mtmips.bin starting USB... Bus ehci at 101c0000: USB EHCI 1.00 scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found 465744 bytes read in 21 ms (21.2 MiB/s) => sf probe; sf update ${fileaddr} 0 ${filesize} SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB device 0 offset 0x0, size 0x71b50 465744 bytes written, 0 bytes skipped in 11.666s, speed 40870 B/s => sf read 86000000 0 ${filesize}; cmp 86000000 ${fileaddr} ${filesize} device 0 offset 0x0, size 0x71b50 SF: 465744 bytes @ 0x0 Read: OK word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020) Total of 116436 word(s) were the same => reset resetting ... <DEAD> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? I assume difference in the very last word (actually the first word out) is significant. As said there could be differences in Bootstrapping pins latching. I will review that after lunch... > > Thanks, > Stefan > Thanks, so far... ;) Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 12:50 ` Mauro Condarelli @ 2020-01-15 15:04 ` Stefan Roese 2020-01-15 15:55 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-15 15:04 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 13:50, Mauro Condarelli wrote: > Hi Stefan, > > On 1/15/20 11:48 AM, Stefan Roese wrote: >> Hi Mauro, >> >> On 15.01.20 11:23, Mauro Condarelli wrote: >>>>> I am surprised though as all I could find on differences between >>>>> MT7628 and MT7688 are is a reference on Mediatek site: >>>>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq >>>>> >>>>> Q: What’s MT7628 and how is it different from MT7688AN? >>>>> >>>>> The MT7628 series are pin-to-pin compatible with the MT7688 series. >>>>> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports >>>>> 1T1R antenna. >>>>> >>>>> (Incomplete!) comparison of the two datasheets did not show >>>>> relevant differences. >>> I have started an analysis of current register status (and I quickly hit >>> limitation of the documentation I have): >>> >>> b0000008: 00010000 .... >>> E-Fuse Configuration is not pristine, but I don't know what it my mean. >>> >>> b0000010: 00111144 D... >>> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 1000 >>> 1000 >> >> Not correct: >> >> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 0100 0100 > Right. > Shame on me. > >>> 00000000 TEST_CODE >>> 000 * >>> 100010001 BS_SHADOW >>> 000 * >>> 1 DBG_JTAG_MODE 1: Normal Boot-up >>> 1 TEST_MODE_1 ?? >>> 0 XTAL_FREQ_SEL 0: 25MHz DIP ??? >>> 0 EXT_BG 0: BG clock from PMU >>> 0 TEST_MODE_0 0: SUTIF >>> 100 CHIP_MODE 100: SCAN mode >> >> Not correct. You have here 010, so XTAL with 3-byte ADR > >> >>> 0 DRAM_TYPE 0: DDR2 >>> >>> I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might >>> signal a different up/down pulling of Bootstrapping Pins. >>> Could You cross check on LinkIt, please? >> >> => md b0000000 >> b0000000: 3637544d 20203832 00100000 00010102 MT7628 ........ >> b0000010: 00156156 02605500 00000000 00000000 Va...U`......... >> b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . >> b0000030: ffffffc0 04000000 c0030004 00fe00ff ................ >> b0000040: 00000000 0001ffff 00000000 00000000 ................ >> b0000050: 00000000 00000000 00000000 00000810 ................ >> b0000060: 50050404 05550551 00000000 00000000 ...PQ.U......... > This is my register dump, for reference: > VoCore2 > md b0000000 > b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ > b0000010: 00144144 02605500 00000000 00000000 DA...U`......... > b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . > b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... > b0000040: 00000000 0001ffff 00000000 00000000 ................ > b0000050: 00000000 00000000 00000000 00000810 ................ > b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... Okay, thanks. We can compare this now in depth. >> >> SYSCFG0: 00156156 >> >> CHIP_MODE: 011: XTAL with 4-byte ADR. >> >> Mainline U-Boot reports this: >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) > My mainline (RAM) reports: > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >> >> and the new code from Weijie reports this: >> >> CPU: MediaTek MT7688A ver:1 eco:2 >> Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL >> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz >> >> One important difference which might explain a lot, it XTAL_FREQ_SEL >> which is 0 in your case and 1 in my case. >> >> IIUTC, then the new code from Weijie takes this XTAL selection >> into account. Weijie might comment on this. I suggest that you give >> this "u-boot-mtmips.bin" binary a try. Good luck. :) > No good ;( Ughhh. Too bad. :-( > Here's transcript: > > VoCore2 > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 > (Re)start USB... > USB0: Mediatek/Ralink USB EHCI > Register 1111 NbrPorts 1 > USB EHCI 1.00 > scanning bus 0 for devices... 3 USB Device(s) found > scanning bus for storage devices... 1 Storage Device(s) found > reading u-boot-ram.bin > ........................................................................... > > 387097 bytes read > ## Starting application at 0x80010000 ... > <debug_uart> board_debug_uart_init(): > board_early_init_f(): > > > U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) > > CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) > Model: VoCore2 > DRAM: 128 MiB > WDT: Started with servicing (60s timeout) > board_early_init_r(): > arch_early_init_r(): > MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): > mmc at 10130000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: uart2 at e00 > Out: uart2 at e00 > Err: uart2 at e00 > Model: VoCore2 > arch_misc_init(): > => usb start; load usb 0:1 85000000 u-boot-mtmips.bin > starting USB... > Bus ehci at 101c0000: USB EHCI 1.00 > scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > 465744 bytes read in 21 ms (21.2 MiB/s) > => sf probe; sf update ${fileaddr} 0 ${filesize} > SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total > 16 MiB > device 0 offset 0x0, size 0x71b50 > 465744 bytes written, 0 bytes skipped in 11.666s, speed 40870 B/s > => sf read 86000000 0 ${filesize}; cmp 86000000 ${fileaddr} ${filesize} > device 0 offset 0x0, size 0x71b50 > SF: 465744 bytes @ 0x0 Read: OK > word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020) > Total of 116436 word(s) were the same > => reset > resetting ... > > <DEAD> > > Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? You don't need to know where it is linked to if you program it into SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000. > I assume difference in the very last word (actually the first word out) > is significant. I don't understand this comment. Please explain. > As said there could be differences in Bootstrapping pins latching. > I will review that after lunch... Okay. Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 15:04 ` Stefan Roese @ 2020-01-15 15:55 ` Mauro Condarelli 2020-01-15 16:20 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-15 15:55 UTC (permalink / raw) To: u-boot On 1/15/20 4:04 PM, Stefan Roese wrote: > Hi Mauro, > > On 15.01.20 13:50, Mauro Condarelli wrote: >> Hi Stefan, >> >> On 1/15/20 11:48 AM, Stefan Roese wrote: >>> Hi Mauro, >>> >>> On 15.01.20 11:23, Mauro Condarelli wrote: >>>>>> I am surprised though as all I could find on differences between >>>>>> MT7628 and MT7688 are is a reference on Mediatek site: >>>>>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq >>>>>> >>>>>> Q: What’s MT7628 and how is it different from MT7688AN? >>>>>> >>>>>> The MT7628 series are pin-to-pin compatible with the MT7688 series. >>>>>> However, MT7628 comes with a 2T2R antenna, while MT7688 only >>>>>> supports >>>>>> 1T1R antenna. >>>>>> >>>>>> (Incomplete!) comparison of the two datasheets did not show >>>>>> relevant differences. >>>> I have started an analysis of current register status (and I >>>> quickly hit >>>> limitation of the documentation I have): >>>> >>>> b0000008: 00010000 .... >>>> E-Fuse Configuration is not pristine, but I don't know what it my >>>> mean. >>>> >>>> b0000010: 00111144 D... >>>> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 1000 >>>> 1000 >>> >>> Not correct: >>> >>> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 0100 >>> 0100 >> Right. >> Shame on me. >> >>>> 00000000 TEST_CODE >>>> 000 * >>>> 100010001 BS_SHADOW >>>> 000 * >>>> 1 DBG_JTAG_MODE 1: Normal Boot-up >>>> 1 TEST_MODE_1 ?? >>>> 0 XTAL_FREQ_SEL 0: 25MHz DIP ??? >>>> 0 EXT_BG 0: BG clock from PMU >>>> 0 TEST_MODE_0 0: SUTIF >>>> 100 CHIP_MODE 100: SCAN mode >>> >>> Not correct. You have here 010, so XTAL with 3-byte ADR >> >>> >>>> 0 DRAM_TYPE 0: DDR2 >>>> >>>> I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might >>>> signal a different up/down pulling of Bootstrapping Pins. >>>> Could You cross check on LinkIt, please? >>> >>> => md b0000000 >>> b0000000: 3637544d 20203832 00100000 00010102 MT7628 ........ >>> b0000010: 00156156 02605500 00000000 00000000 Va...U`......... >>> b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . >>> b0000030: ffffffc0 04000000 c0030004 00fe00ff ................ >>> b0000040: 00000000 0001ffff 00000000 00000000 ................ >>> b0000050: 00000000 00000000 00000000 00000810 ................ >>> b0000060: 50050404 05550551 00000000 00000000 ...PQ.U......... >> This is my register dump, for reference: >> VoCore2 > md b0000000 >> b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ >> b0000010: 00144144 02605500 00000000 00000000 DA...U`......... >> b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . >> b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... >> b0000040: 00000000 0001ffff 00000000 00000000 ................ >> b0000050: 00000000 00000000 00000000 00000810 ................ >> b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... > > Okay, thanks. We can compare this now in depth. On this machine (theoretically identical to the previous one; now useless till I reflash it) register dump is a bit different: VoCore2 > md b0000000 b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ b0000010: 00065144 02605500 00000000 00000000 DQ...U`......... b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... b0000040: 00000000 0001ffff 00000000 00000000 ................ b0000050: 00000000 00000000 00000000 00000810 ................ b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... in particular: b0000010: 00065144 System Configuration Register 0 ->0000 0000 0000 0110 0101 0001 0100 0100 0000 0000 TEST_CODE : None 000 Reserved 0 0110 0101 BS_SHADOW : ??? 000 Rseserved 1 DBG_JTAG_MODE 1: Normal Boot-up 0 TEST_MODE_1 : ??? 1 XTAL_FREQ_SEL 1: 40MHz SMD (3225) 0 EXT_BG 0: BG clock from PMU 0 TEST_MODE_0 0: SUTIF 010 CHIP_MODE 010: Boot from XTAL (boot from SPI 3-Byte ADR) 0 DRAM_TYPE 0: DDR2 which looks good to me; as said the only difference is the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant? AFAIK my soldered SPI NOR: SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total has 3-Byte SPI Address. From data sheet: The Read Data Bytes (READ) command is followed by a 3-byte address (A23-A0), ... What is on LinkIt? Does that change anything in u-boot? >>> SYSCFG0: 00156156 >>> >>> CHIP_MODE: 011: XTAL with 4-byte ADR. >>> >>> Mainline U-Boot reports this: >>> >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) >> My mainline (RAM) reports: >> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>> >>> and the new code from Weijie reports this: >>> >>> CPU: MediaTek MT7688A ver:1 eco:2 >>> Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL >>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz >>> >>> One important difference which might explain a lot, it XTAL_FREQ_SEL >>> which is 0 in your case and 1 in my case. >>> >>> IIUTC, then the new code from Weijie takes this XTAL selection >>> into account. Weijie might comment on this. I suggest that you give >>> this "u-boot-mtmips.bin" binary a try. Good luck. :) >> No good ;( > > Ughhh. Too bad. :-( Don't tell me ;( >> Here's transcript: >> >> VoCore2 > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 >> (Re)start USB... >> USB0: Mediatek/Ralink USB EHCI >> Register 1111 NbrPorts 1 >> USB EHCI 1.00 >> scanning bus 0 for devices... 3 USB Device(s) found >> scanning bus for storage devices... 1 Storage Device(s) found >> reading u-boot-ram.bin >> ........................................................................... >> >> >> 387097 bytes read >> ## Starting application at 0x80010000 ... >> <debug_uart> board_debug_uart_init(): >> board_early_init_f(): >> >> >> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >> Model: VoCore2 >> DRAM: 128 MiB >> WDT: Started with servicing (60s timeout) >> board_early_init_r(): >> arch_early_init_r(): >> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >> mmc at 10130000: 0 >> Loading Environment from FAT... *** Warning - bad CRC, using default >> environment >> >> In: uart2 at e00 >> Out: uart2 at e00 >> Err: uart2 at e00 >> Model: VoCore2 >> arch_misc_init(): >> => usb start; load usb 0:1 85000000 u-boot-mtmips.bin >> starting USB... >> Bus ehci at 101c0000: USB EHCI 1.00 >> scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> 465744 bytes read in 21 ms (21.2 MiB/s) >> => sf probe; sf update ${fileaddr} 0 ${filesize} >> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total >> 16 MiB >> device 0 offset 0x0, size 0x71b50 >> 465744 bytes written, 0 bytes skipped in 11.666s, speed 40870 B/s >> => sf read 86000000 0 ${filesize}; cmp 86000000 ${fileaddr} ${filesize} >> device 0 offset 0x0, size 0x71b50 >> SF: 465744 bytes @ 0x0 Read: OK >> word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020) >> Total of 116436 word(s) were the same >> => reset >> resetting ... >> >> <DEAD> >> >> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? > > You don't need to know where it is linked to if you program it into > SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000. Can You elaborate, please? I know for sure that if I flash at 30000 a u-boot that has been compiled with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000" I need to rebuild with SYS_TEXT_BASE = 0x9c030000. >> I assume difference in the very last word (actually the first word out) >> is significant. > > I don't understand this comment. Please explain. CMP reports: "word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020)" but I flashed "size 0x71b50" bytes (from 0) so 0x86071b50 is actually the first byte *beyond* flashed area; apparently CMP compares a byte too much (if I'm not mistaken again, of course). >> As said there could be differences in Bootstrapping pins latching. >> I will review that after lunch... > > Okay. I fear I'll have to resort to implementing some JTAG interface to solve this. I have never used such a hardware debugger on this class of processors (they are pretty useless under Linux), do You have any experience and/or feel like recommending a specific (possibly low-cost) pod/debugger? > Thanks, > Stefan Many Thanks Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 15:55 ` Mauro Condarelli @ 2020-01-15 16:20 ` Stefan Roese 2020-01-15 17:25 ` Mauro Condarelli 0 siblings, 1 reply; 30+ messages in thread From: Stefan Roese @ 2020-01-15 16:20 UTC (permalink / raw) To: u-boot On 15.01.20 16:55, Mauro Condarelli wrote: <snip> >>>> => md b0000000 >>>> b0000000: 3637544d 20203832 00100000 00010102 MT7628 ........ >>>> b0000010: 00156156 02605500 00000000 00000000 Va...U`......... >>>> b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . >>>> b0000030: ffffffc0 04000000 c0030004 00fe00ff ................ >>>> b0000040: 00000000 0001ffff 00000000 00000000 ................ >>>> b0000050: 00000000 00000000 00000000 00000810 ................ >>>> b0000060: 50050404 05550551 00000000 00000000 ...PQ.U......... >>> This is my register dump, for reference: >>> VoCore2 > md b0000000 >>> b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ >>> b0000010: 00144144 02605500 00000000 00000000 DA...U`......... >>> b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . >>> b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... >>> b0000040: 00000000 0001ffff 00000000 00000000 ................ >>> b0000050: 00000000 00000000 00000000 00000810 ................ >>> b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... >> >> Okay, thanks. We can compare this now in depth. > On this machine (theoretically identical to the previous one; now > useless till > I reflash it) register dump is a bit different: > > VoCore2 > md b0000000 > b0000000: 3637544d 20203832 00010000 00010102 MT7628 ........ > b0000010: 00065144 02605500 00000000 00000000 DQ...U`......... > b0000020: 10240000 00000000 00000071 0020100c ..$.....q..... . > b0000030: f9bfffc0 06400000 c0030200 00fe01ff ...... at ......... > b0000040: 00000000 0001ffff 00000000 00000000 ................ > b0000050: 00000000 00000000 00000000 00000810 ................ > b0000060: 5505040c 05540555 00000000 00000000 ...UU.T......... > > in particular: > > b0000010: 00065144 > System Configuration Register 0 ->0000 0000 0000 0110 0101 0001 0100 0100 > 0000 0000 TEST_CODE : None > 000 Reserved > 0 0110 0101 BS_SHADOW : ??? > 000 Rseserved > 1 DBG_JTAG_MODE 1: Normal Boot-up > 0 TEST_MODE_1 : ??? > 1 XTAL_FREQ_SEL 1: 40MHz SMD (3225) > 0 EXT_BG 0: BG clock from PMU > 0 TEST_MODE_0 0: SUTIF > 010 CHIP_MODE 010: Boot from XTAL (boot from SPI 3-Byte ADR) > 0 DRAM_TYPE 0: DDR2 > > which looks good to me; as said the only difference is > the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant? > AFAIK my soldered SPI NOR: > > SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total > > has 3-Byte SPI Address. From data sheet: > The Read Data Bytes (READ) command is followed by a 3-byte address > (A23-A0), ... > What is on LinkIt? Its strapped to 4-byte. And on the GARDENA board as well. > Does that change anything in u-boot? I would not expect this to change anything, if its configured to 3-byte other that that you can't access anything above 16 MiB. If you are really out of ideas and its possible for you, then please change the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description". >>>> SYSCFG0: 00156156 >>>> >>>> CHIP_MODE: 011: XTAL with 4-byte ADR. >>>> >>>> Mainline U-Boot reports this: >>>> >>>> CPU: MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) >>> My mainline (RAM) reports: >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>>> >>>> and the new code from Weijie reports this: >>>> >>>> CPU: MediaTek MT7688A ver:1 eco:2 >>>> Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL >>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz >>>> >>>> One important difference which might explain a lot, it XTAL_FREQ_SEL >>>> which is 0 in your case and 1 in my case. >>>> >>>> IIUTC, then the new code from Weijie takes this XTAL selection >>>> into account. Weijie might comment on this. I suggest that you give >>>> this "u-boot-mtmips.bin" binary a try. Good luck. :) >>> No good ;( >> >> Ughhh. Too bad. :-( > Don't tell me ;( > >>> Here's transcript: >>> >>> VoCore2 > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000 >>> (Re)start USB... >>> USB0: Mediatek/Ralink USB EHCI >>> Register 1111 NbrPorts 1 >>> USB EHCI 1.00 >>> scanning bus 0 for devices... 3 USB Device(s) found >>> scanning bus for storage devices... 1 Storage Device(s) found >>> reading u-boot-ram.bin >>> ........................................................................... >>> >>> >>> 387097 bytes read >>> ## Starting application at 0x80010000 ... >>> <debug_uart> board_debug_uart_init(): >>> board_early_init_f(): >>> >>> >>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100) >>> >>> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >>> Model: VoCore2 >>> DRAM: 128 MiB >>> WDT: Started with servicing (60s timeout) >>> board_early_init_r(): >>> arch_early_init_r(): >>> MMC: pinctrl_select_state_full('mmc at 10130000', 'default'): >>> mmc at 10130000: 0 >>> Loading Environment from FAT... *** Warning - bad CRC, using default >>> environment >>> >>> In: uart2 at e00 >>> Out: uart2 at e00 >>> Err: uart2 at e00 >>> Model: VoCore2 >>> arch_misc_init(): >>> => usb start; load usb 0:1 85000000 u-boot-mtmips.bin >>> starting USB... >>> Bus ehci at 101c0000: USB EHCI 1.00 >>> scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found >>> scanning usb for storage devices... 1 Storage Device(s) found >>> 465744 bytes read in 21 ms (21.2 MiB/s) >>> => sf probe; sf update ${fileaddr} 0 ${filesize} >>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total >>> 16 MiB >>> device 0 offset 0x0, size 0x71b50 >>> 465744 bytes written, 0 bytes skipped in 11.666s, speed 40870 B/s >>> => sf read 86000000 0 ${filesize}; cmp 86000000 ${fileaddr} ${filesize} >>> device 0 offset 0x0, size 0x71b50 >>> SF: 465744 bytes @ 0x0 Read: OK >>> word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020) >>> Total of 116436 word(s) were the same >>> => reset >>> resetting ... >>> >>> <DEAD> >>> >>> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? >> >> You don't need to know where it is linked to if you program it into >> SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000. > Can You elaborate, please? Each image generated to boot from SPI NOR needs to be linked to 9c000000. This is what the ROM image (non-RAM) of mainline does and the SPL image of the dual image version (SPL plus main U-Boot proper) does. > I know for sure that if I flash at 30000 a u-boot that has been compiled > with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000" > I need to rebuild with SYS_TEXT_BASE = 0x9c030000. But you flash at offset 0 in SPI NOR, right? That's where the SoC starts reading the bootloader binary after a reset or on power-up. >>> I assume difference in the very last word (actually the first word out) >>> is significant. >> >> I don't understand this comment. Please explain. > CMP reports: "word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 > (0x2a8d0020)" > but I flashed "size 0x71b50" bytes (from 0) so 0x86071b50 is actually > the first byte *beyond* > flashed area; apparently CMP compares a byte too much (if I'm not > mistaken again, of course). Ah now I see what your problem is here. You need to specific ".b" in the "cmp" command. Other longwords are compared and counted. So it needs to be: => cmp.b 86000000 ${fileaddr} ${filesize} This should work and generate no errors. >>> As said there could be differences in Bootstrapping pins latching. >>> I will review that after lunch... >> >> Okay. > I fear I'll have to resort to implementing some JTAG interface to solve > this. > I have never used such a hardware debugger on this class of processors > (they are pretty useless under Linux), do You have any experience and/or > feel like recommending a specific (possibly low-cost) pod/debugger? I do have experience with JTAG debuggers. But I do have zero experience with JTAG debugging on this MIPS SoC. So I can't really help here. I did all my porting by using the DEBUG UART and before that by using an LED that I triggered very early in the assembly code. Not sure if such an LED exists for you. Its not that easy and the DEBUG UART is much better suited. Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 16:20 ` Stefan Roese @ 2020-01-15 17:25 ` Mauro Condarelli 2020-01-16 6:33 ` Stefan Roese 0 siblings, 1 reply; 30+ messages in thread From: Mauro Condarelli @ 2020-01-15 17:25 UTC (permalink / raw) To: u-boot On 1/15/20 5:20 PM, Stefan Roese wrote: > On 15.01.20 16:55, Mauro Condarelli wrote: > > <snip> ===8<------ > in particular: >> >> b0000010: 00065144 >> System Configuration Register 0 ->0000 0000 0000 0110 0101 0001 0100 >> 0100 >> 0000 0000 TEST_CODE : None >> 000 Reserved >> 0 0110 0101 BS_SHADOW : ??? >> 000 Rseserved >> 1 DBG_JTAG_MODE 1: Normal Boot-up >> 0 TEST_MODE_1 : ??? >> 1 XTAL_FREQ_SEL 1: 40MHz SMD (3225) >> 0 EXT_BG 0: BG clock from PMU >> 0 TEST_MODE_0 0: SUTIF >> 010 CHIP_MODE 010: Boot from XTAL (boot from SPI 3-Byte >> ADR) >> 0 DRAM_TYPE 0: DDR2 >> >> which looks good to me; as said the only difference is >> the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant? >> AFAIK my soldered SPI NOR: >> >> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total >> >> has 3-Byte SPI Address. From data sheet: >> The Read Data Bytes (READ) command is followed by a 3-byte address >> (A23-A0), ... >> What is on LinkIt? > > Its strapped to 4-byte. And on the GARDENA board as well. > >> Does that change anything in u-boot? > > I would not expect this to change anything, if its configured to 3-byte > other that that you can't access anything above 16 MiB. My SPI NOR is 16 MiB, so I cannot access anything beyond that ;) > If you are really out of ideas and its possible for you, then please > change > the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description". That wouldn't be easy as it's a SMD resistor soldered directly on the Module. Let's keep that as "last resort". ===8<------ >> >>>> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? >>> >>> You don't need to know where it is linked to if you program it into >>> SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000. >> Can You elaborate, please? > > Each image generated to boot from SPI NOR needs to be linked to 9c000000. > This is what the ROM image (non-RAM) of mainline does and the SPL image > of the dual image version (SPL plus main U-Boot proper) does. > >> I know for sure that if I flash at 30000 a u-boot that has been compiled >> with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000" >> I need to rebuild with SYS_TEXT_BASE = 0x9c030000. > > But you flash at offset 0 in SPI NOR, right? That's where the SoC starts > reading the bootloader binary after a reset or on power-up. I was trying to say that, in my "secondary u-boot" attempts, where I start from "paleolithic" and then do a "go <addr>" I need to put the secondary at the same address specified in SYS_TEXT_BASE. I mean: if I want to boot directly from new then SYS_TEXT_BASE = 0x9c000000 flash at start of SPI NOR go 9c000000 else if I want to start "secondary" then SYS_TEXT_BASE = 0x9c030000 flash at offset 30000 in SPI NOR go 9c030000 Any other combination does not work (i.e.: I cannot flash and run at start an u-boot compiled with SYS_TEXT_BASE = 0x9c030000 and vice versa). Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently it is visible in menuconfig only for ARM; am I missing something? > ===8<------ I do have a led I can use for crude signalling, but I'm not really familiar with mips Assembly. Can You share the code to turn it on? (it is connected to GPIO44/WLED(pin144). > > Thanks, > Stefan > TiA! Mauro ^ permalink raw reply [flat|nested] 30+ messages in thread
* Debugging VoCore2 ROM Startup 2020-01-15 17:25 ` Mauro Condarelli @ 2020-01-16 6:33 ` Stefan Roese 0 siblings, 0 replies; 30+ messages in thread From: Stefan Roese @ 2020-01-16 6:33 UTC (permalink / raw) To: u-boot Hi Mauro, On 15.01.20 18:25, Mauro Condarelli wrote: >>> >>>>> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right? >>>> >>>> You don't need to know where it is linked to if you program it into >>>> SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000. >>> Can You elaborate, please? >> >> Each image generated to boot from SPI NOR needs to be linked to 9c000000. >> This is what the ROM image (non-RAM) of mainline does and the SPL image >> of the dual image version (SPL plus main U-Boot proper) does. >> >>> I know for sure that if I flash at 30000 a u-boot that has been compiled >>> with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000" >>> I need to rebuild with SYS_TEXT_BASE = 0x9c030000. >> >> But you flash at offset 0 in SPI NOR, right? That's where the SoC starts >> reading the bootloader binary after a reset or on power-up. > I was trying to say that, in my "secondary u-boot" attempts, where I > start from "paleolithic" and then do a "go <addr>" I need to put the > secondary at the same address specified in SYS_TEXT_BASE. > I mean: > if I want to boot directly from new then > SYS_TEXT_BASE = 0x9c000000 > flash at start of SPI NOR > go 9c000000 > else if I want to start "secondary" then > SYS_TEXT_BASE = 0x9c030000 > flash at offset 30000 in SPI NOR > go 9c030000 > Any other combination does not work (i.e.: I cannot flash and run at > start an u-boot compiled with SYS_TEXT_BASE = 0x9c030000 and > vice versa). > > Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently > it is visible in menuconfig only for ARM; am I missing something? I can change it for my LinkIt target via "make menuconfig". Just search for it by entering "/" in "make menuconfig" and it should show up there. >> > ===8<------ > > I do have a led I can use for crude signalling, but I'm not really familiar > with mips Assembly. > Can You share the code to turn it on? (it is connected to > GPIO44/WLED(pin144). i don't remember but it might be the case. Here the code snippet that I used at that time. Perhaps it helps: +#if 0 // test-only: WLAN LED on +#define RALINK_SYSCTL_BASE 0xB0000000 + // GPIO mode + li t0, RALINK_SYSCTL_BASE + 0x64 + li t1, 0x05540551 + sw t1, 0(t0) + + // GPIO direction + li t0, RALINK_SYSCTL_BASE + 0x604 + li t1, 0x00001000 + sw t1, 0(t0) + + // GPIO value + li t0, RALINK_SYSCTL_BASE + 0x624 + li t1, 0x0002f5f + sw t1, 0(t0) +#endif Thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2020-01-16 6:33 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-09 17:28 How to debug HW startup? Mauro Condarelli 2020-01-10 6:31 ` Stefan Roese 2020-01-10 9:06 ` Mauro Condarelli 2020-01-10 13:33 ` Stefan Roese 2020-01-11 19:00 ` Mauro Condarelli 2020-01-11 20:42 ` Sean Anderson 2020-01-11 21:38 ` Mauro Condarelli 2020-01-11 23:58 ` Sean Anderson 2020-01-12 0:22 ` Mauro Condarelli 2020-01-13 6:53 ` Stefan Roese 2020-01-13 10:24 ` Mauro Condarelli 2020-01-13 11:39 ` Stefan Roese 2020-01-13 12:24 ` Mauro Condarelli 2020-01-13 12:45 ` Stefan Roese 2020-01-13 14:14 ` Mauro Condarelli 2020-01-13 23:08 ` Mauro Condarelli 2020-01-14 11:03 ` Mauro Condarelli 2020-01-14 23:55 ` Debugging VoCore2 ROM Startup (was: How to debug HW startup?) Mauro Condarelli 2020-01-15 7:25 ` Debugging VoCore2 ROM Startup Stefan Roese 2020-01-15 9:04 ` Mauro Condarelli 2020-01-15 9:31 ` Stefan Roese 2020-01-15 9:51 ` Stefan Roese 2020-01-15 10:23 ` Mauro Condarelli 2020-01-15 10:48 ` Stefan Roese 2020-01-15 12:50 ` Mauro Condarelli 2020-01-15 15:04 ` Stefan Roese 2020-01-15 15:55 ` Mauro Condarelli 2020-01-15 16:20 ` Stefan Roese 2020-01-15 17:25 ` Mauro Condarelli 2020-01-16 6:33 ` Stefan Roese
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.