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
