Debugging VoCore2 ROM Startup

[Mauro Condarelli <mc5686@mclink.it>]

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