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
