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 ......@.........
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?
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@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?
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
