Debugging VoCore2 ROM Startup

Wed Jan 15 16:55:31 CET 2020

On 1/15/20 4:04 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.01.20 13:50, Mauro Condarelli wrote:
>> Hi Stefan,
>>
>> On 1/15/20 11:48 AM, Stefan Roese wrote:
>>> Hi Mauro,
>>>
>>> On 15.01.20 11:23, Mauro Condarelli wrote:
>>>>>> 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
>>>
>>> Not correct:
>>>
>>> System Configuration Register 0 ->0000 0000 0001 0001 0001 0001 0100
>>> 0100
>> Right.
>> Shame on me.
>>
>>>> 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
>>>
>>> Not correct. You have here 010, so XTAL with 3-byte ADR
>>
>>>
>>>> 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?
>>>
>>> => md b0000000
>>> b0000000: 3637544d 20203832 00100000 00010102    MT7628  ........
>>> b0000010: 00156156 02605500 00000000 00000000    Va...U`.........
>>> b0000020: 10240000 00000000 00000071 0020100c    ..$.....q..... .
>>> b0000030: ffffffc0 04000000 c0030004 00fe00ff    ................
>>> b0000040: 00000000 0001ffff 00000000 00000000    ................
>>> b0000050: 00000000 00000000 00000000 00000810    ................
>>> b0000060: 50050404 05550551 00000000 00000000    ...PQ.U.........
>> This is my register dump, for reference:
>> VoCore2 > md b0000000
>> b0000000: 3637544d 20203832 00010000 00010102    MT7628  ........
>> b0000010: 00144144 02605500 00000000 00000000    DA...U`.........
>> b0000020: 10240000 00000000 00000071 0020100c    ..$.....q..... .
>> b0000030: f9bfffc0 06400000 c0030200 00fe01ff    ...... at .........
>> b0000040: 00000000 0001ffff 00000000 00000000    ................
>> b0000050: 00000000 00000000 00000000 00000810    ................
>> b0000060: 5505040c 05540555 00000000 00000000    ...UU.T.........
>
> Okay, thanks. We can compare this now in depth.
On this machine (theoretically identical to the previous one; now
useless till
I reflash it) register dump is a bit different:

VoCore2 > md b0000000
b0000000: 3637544d 20203832 00010000 00010102    MT7628  ........
b0000010: 00065144 02605500 00000000 00000000    DQ...U`.........
b0000020: 10240000 00000000 00000071 0020100c    ..$.....q..... .
b0000030: f9bfffc0 06400000 c0030200 00fe01ff    ...... at .........
b0000040: 00000000 0001ffff 00000000 00000000    ................
b0000050: 00000000 00000000 00000000 00000810    ................
b0000060: 5505040c 05540555 00000000 00000000    ...UU.T.........

in particular:

b0000010: 00065144
System Configuration Register 0 ->0000 0000 0000 0110 0101 0001 0100 0100
0000 0000   TEST_CODE         : None
000         Reserved
0 0110 0101 BS_SHADOW         : ???
000         Rseserved
1           DBG_JTAG_MODE    1: Normal Boot-up
0           TEST_MODE_1       : ???
1           XTAL_FREQ_SEL    1: 40MHz SMD (3225)
0           EXT_BG           0: BG clock from PMU
0           TEST_MODE_0      0: SUTIF
010         CHIP_MODE      010: Boot from XTAL (boot from SPI 3-Byte ADR)
0           DRAM_TYPE        0: DDR2

which looks good to me; as said the only difference is
the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant?
AFAIK my soldered SPI NOR:

SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total

has 3-Byte SPI Address. From data sheet:
The Read Data Bytes (READ) command is followed by a 3-byte address
(A23-A0), ...
What is on LinkIt?
Does that change anything in u-boot?

>>> SYSCFG0: 00156156
>>>
>>> CHIP_MODE: 011: XTAL with 4-byte ADR.
>>>
>>> Mainline U-Boot reports this:
>>>
>>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr)
>> My mainline (RAM) reports:
>>      CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>>>
>>> and the new code from Weijie reports this:
>>>
>>> CPU:   MediaTek MT7688A ver:1 eco:2
>>> Boot:  DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL
>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>
>>> One important difference which might explain a lot, it XTAL_FREQ_SEL
>>> which is 0 in your case and 1 in my case.
>>>
>>> IIUTC, then the new code from Weijie takes this XTAL selection
>>> into account. Weijie might comment on this. I suggest that you give
>>> this "u-boot-mtmips.bin" binary a try. Good luck. :)
>> No good ;(
>
> Ughhh. Too bad. :-(
Don't tell me ;(

>> Here's transcript:
>>
>> VoCore2 > usb reset; fatload usb 0 80010000 u-boot-ram.bin; go 80010000
>> (Re)start USB...
>> USB0:  Mediatek/Ralink USB EHCI
>> Register 1111 NbrPorts 1
>> USB EHCI 1.00
>> scanning bus 0 for devices... 3 USB Device(s) found
>>         scanning bus for storage devices... 1 Storage Device(s) found
>> reading u-boot-ram.bin
>> ...........................................................................
>>
>>
>> 387097 bytes read
>> ## Starting application at 0x80010000 ...
>> <debug_uart> board_debug_uart_init():
>> board_early_init_f():
>>
>>
>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)
>>
>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>> Model: VoCore2
>> DRAM:  128 MiB
>> WDT:   Started with servicing (60s timeout)
>> board_early_init_r():
>> arch_early_init_r():
>> MMC:   pinctrl_select_state_full('mmc at 10130000', 'default'):
>> mmc at 10130000: 0
>> Loading Environment from FAT... *** Warning - bad CRC, using default
>> environment
>>
>> In:    uart2 at e00
>> Out:   uart2 at e00
>> Err:   uart2 at e00
>> Model: VoCore2
>> arch_misc_init():
>> => usb start; load usb 0:1 85000000 u-boot-mtmips.bin
>> starting USB...
>> Bus ehci at 101c0000: USB EHCI 1.00
>> scanning bus ehci at 101c0000 for devices... 3 USB Device(s) found
>>         scanning usb for storage devices... 1 Storage Device(s) found
>> 465744 bytes read in 21 ms (21.2 MiB/s)
>> => sf probe; sf update ${fileaddr} 0 ${filesize}
>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
>> 16 MiB
>> device 0 offset 0x0, size 0x71b50
>> 465744 bytes written, 0 bytes skipped in 11.666s, speed 40870 B/s
>> => sf read 86000000 0 ${filesize}; cmp 86000000 ${fileaddr} ${filesize}
>> device 0 offset 0x0, size 0x71b50
>> SF: 465744 bytes @ 0x0 Read: OK
>> word at 0x86071b50 (0x933a51e7) != word at 0x85071b50 (0x2a8d0020)
>> Total of 116436 word(s) were the same
>> => reset
>> resetting ...
>>
>> <DEAD>
>>
>> Note: I assumed u-boot-mtmips.bin is linked at 9c000000, right?
>
> You don't need to know where it is linked to if you program it into
> SPI NOR. But yes, the first stage the SPL is linked to 0x9c000000.
Can You elaborate, please?
I know for sure that if I flash at 30000 a u-boot that has been compiled
with SYS_TEXT_BASE = 0x9c000000 it will not start with "go 9c030000"
I need to rebuild with SYS_TEXT_BASE = 0x9c030000.

>> I assume difference in the very last word (actually the first word out)
>> is significant.
>
> I don't understand this comment. Please explain.
CMP reports: "word at 0x86071b50 (0x933a51e7) != word at 0x85071b50
(0x2a8d0020)"
but I flashed "size 0x71b50" bytes (from 0) so 0x86071b50 is actually
the first byte *beyond*
flashed area; apparently CMP compares a byte too much (if I'm not
mistaken again, of course).

>> As said there could be differences in Bootstrapping pins latching.
>> I will review that after lunch...
>
> Okay.
I fear I'll have to resort to implementing some JTAG interface to solve
this.
I have never used such a hardware debugger on this class of processors
(they are pretty useless under Linux), do You have any experience and/or
feel like recommending a specific (possibly low-cost) pod/debugger?

> Thanks,
> Stefan
Many Thanks
Mauro