Debugging VoCore2 ROM Startup
Stefan Roese
sr at denx.de
Wed Jan 15 17:20:39 CET 2020
On 15.01.20 16:55, Mauro Condarelli wrote:
<snip>
>>>> => 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?
Its strapped to 4-byte. And on the GARDENA board as well.
> Does that change anything in u-boot?
I would not expect this to change anything, if its configured to 3-byte
other that that you can't access anything above 16 MiB.
If you are really out of ideas and its possible for you, then please change
the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description".
>>>> 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?
Each image generated to boot from SPI NOR needs to be linked to 9c000000.
This is what the ROM image (non-RAM) of mainline does and the SPL image
of the dual image version (SPL plus main U-Boot proper) does.
> 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.
But you flash at offset 0 in SPI NOR, right? That's where the SoC starts
reading the bootloader binary after a reset or on power-up.
>>> 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).
Ah now I see what your problem is here. You need to specific ".b" in
the "cmp" command. Other longwords are compared and counted. So it needs
to be:
=> cmp.b 86000000 ${fileaddr} ${filesize}
This should work and generate no errors.
>>> 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?
I do have experience with JTAG debuggers. But I do have zero experience
with JTAG debugging on this MIPS SoC. So I can't really help here. I did
all my porting by using the DEBUG UART and before that by using an LED
that I triggered very early in the assembly code. Not sure if such an
LED exists for you. Its not that easy and the DEBUG UART is much better
suited.
Thanks,
Stefan
More information about the U-Boot
mailing list