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 ......@......... 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 ......@......... 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@10130000', 'default'): mmc@10130000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment
In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 arch_misc_init(): => usb start; load usb 0:1 85000000 u-boot-mtmips.bin starting USB... Bus ehci@101c0000: USB EHCI 1.00 scanning bus ehci@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