Debugging VoCore2 ROM Startup

[Mauro Condarelli]

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