Debugging VoCore2 ROM Startup

[Stefan Roese]

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