Thanks Joel, unfortunately I already have that defined, even if I forgot to copy it. I attach my full .config for reference as I have no idea what I'm still missing.

On 1/11/20 9:42 PM, Sean Anderson wrote:

...

Could You share a Linkit _defconfig with early serial debug enabled? I'm decidedly missing something as, even enabling

CONFIG_DEBUG_UART=y CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y

I still have plenty of errors:

/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: arch/mips/cpu/start.o: in function `wr_done': (.text+0x650): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: (.text+0x654): undefined reference to `debug_uart_init' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: board/vocore/vocore2/built-in.o: in function `board_early_init_f': (.text.board_early_init_f+0x10): undefined reference to `printhex8' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `putc': (.text.putc+0x18): undefined reference to `printch' /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd: common/built-in.o: in function `puts': (.text.puts+0x2c): undefined reference to `printch'

You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550.

As said I have it, but I'm not sure about the other parameters. Maybe a better choice would be CONFIG_DEBUG_UART_MTK. Having a "known good" configuration would help a lot.

Regards Mauro

Many thanks. It appears I had completely misinterpreted the meaning of  CONFIG_DEBUG_UART_CLOCK.

I see now a correct output and a new warning message:

pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

right after "<debug_uart>" notification. Tomorrow I'll try to understand what it means.

I don't think I would have found it without You pointing in  the right direction.

MANY Thanks! Best regards Mauro Condarelli

On 1/12/20 12:58 AM, Sean Anderson wrote:

On 1/11/20 4:38 PM, Mauro Condarelli wrote:

...

Thanks Joel, unfortunately I already have that defined, even if I forgot to copy it. I attach my full .config for reference as I have no idea what I'm still missing.

On 1/11/20 9:42 PM, Sean Anderson wrote:

...

...

Could You share a Linkit _defconfig with early serial debug enabled? I'm decidedly missing something as, even enabling

CONFIG_DEBUG_UART=y CONFIG_DEBUG_UART_BASE=0x10000e00 CONFIG_DEBUG_UART_CLOCK=20 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y

So it looks like your clock is way too low. The unit for the clock is Hz. From the device tree you sent, this board is based off arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this board is compatible with "mediatek,mt7628-clk", and the driver is located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2 clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate, the peripheral clock source depends on the value of PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the data sheet). Therefore, the else clause is taken (unless configured otherwise), so you should use 40000000 for your clock.

...

...

You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550.

As said I have it, but I'm not sure about the other parameters. Maybe a better choice would be CONFIG_DEBUG_UART_MTK. Having a "known good" configuration would help a lot.

Regards Mauro

Hi Stefan,

On 1/13/20 7:53 AM, Stefan Roese wrote:

Hi Mauro,

On 11.01.20 20:00, Mauro Condarelli wrote:

...

I managed to find ONE of the reasons why my ROM build didn't run: I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.

I see. This explains of course, why your board does not boot without any "preloader".

...

I wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below).

Are these issues now fixed? I scanned the discussion about the DEBUG UART on the list. Is this working for you now or do you have any other issues still? Did you successfully boot your new U-Boot from SPI NOR?

Yes and no :(

I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach  my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure).

I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl@60 is not yet setup correctly?). This is the output I get from RAM-based u-boot:

<debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):

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 pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT:   Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC:   pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): 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(): =>

ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required).

The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course!

If I have to resort to that clumsy method, would be enough to put  "new" in  SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000 Did I forget something?

<snip>

...

...

You might also want to give the new version / patches from Weijie a try. He added SPL support and a "cleaner" init code for this SoC.

I'm interested in giving it a spin (and help debugging on another HW, if needed), but I would like to have a solid base from where to move, changing too many things at once is rarely a good strategy ;)

I fully agree.

I need to be able to start from SPI NOR, before I can commit to some other task

Thanks, Stefan

Many thanks Mauro

On 1/13/20 12:39 PM, Stefan Roese wrote:

Hi Mauro,

On 13.01.20 11:24, Mauro Condarelli wrote:

...

On 1/13/20 7:53 AM, Stefan Roese wrote:

...

Hi Mauro,

On 11.01.20 20:00, Mauro Condarelli wrote:

...

I managed to find ONE of the reasons why my ROM build didn't run: I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.

I see. This explains of course, why your board does not boot without any "preloader".

...

I wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below).

Are these issues now fixed? I scanned the discussion about the DEBUG UART on the list. Is this working for you now or do you have any other issues still? Did you successfully boot your new U-Boot from SPI NOR?

Yes and no :(

I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach  my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure).

Before looking into this in more depth (I actually do have problems sleeping though, so I might take a look at it later ;)), why don't you re-start with your defconfig by using the linkit defconfig file. If you are lucky, the LinkIt binary might even work for the VoCore2. Or what are the differences except the SoC type and WLAN? Its the same DDR2 config and the same UART. So it might get you pretty far - also with ROM based booting.

I will try it. Just to be on the safe side, could You attach a binary (or two: ROM and RAM) to the mail? If it works it would really give me a start base.

...

I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl@60 is not yet setup correctly?). This is the output I get from RAM-based u-boot:

<debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):

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 pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT:   Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC:   pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): 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(): =>

I don't have all these pinctrl issues on LinkIt. I suspect a config issue and / or dts issue. Please compare.

I will, but I was trying to say something different: Apparently the stock software tries to initialize uart2 pinctrl and it *seems* to succeed later in initialization. This *seems* to indicate explicit pin setup in board_early_init_f() is not strictly needed (we would lose only the first few lines even if we don't fix the error). I had a look to pinctrl-mt7628.c and it seems to do the right thing upon call to ('uart2_pins', 'default'), so anything after that *should* work even without low-level setup.

...

ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required).

Yes. JTAG requires soldering IIRC.

...

The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course!

If I have to resort to that clumsy method, would be enough to put  "new" in  SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000

This is the TEXT_BASE for ROM based booting:

CONFIG_SYS_TEXT_BASE=0x9c000000

AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory region, the latter being uncached. I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some space for "old" (possibly crippled) u-boot doing initialization and then "jumping" to "new".

Please see configs/linkit-smart-7688_defconfig.

...

Did I forget something?

Not sure. I still think using the linkit port as a base for SPI NOR based booting would be a very good test at least. Do you see any problems with this approach (board / SoC differences)?

No. I see no troubles, for a basic startup. MMC would probably need some changes, but that can come later. As said: I would like to try a prebuilt binary as first thing, so I can be sure I have no other problems (like gcc version or other local variations); then I would try to reproduce locally the equivalent binary with no changes and finally I would try to incorporate my specific needs. What do You think?

Thanks, Stefan

Best regards and TiA! Mauro

Hi Stefan, unfortunately it does *not* work.

Ram based is ok, but rom  is just as silent as mine:

=> usb start; sf probe; starting USB... Bus ehci@101c0000: pinctrl_select_state_full('ehci@101c0000', 'default'): 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 pinctrl_select_state_full('spi@b00', 'default'): SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load usb 0:1 85000000 u-boot_linkit.bin-rom 455708 bytes read in 22 ms (19.8 MiB/s) => sf update ${fileaddr} 0 ${filesize} device 0 offset 0x0, size 0x6f41c 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s => reset resetting ... pinctrl_select_state_full('syscon-reboot', 'default'): pinctrl_select_state_full('system-controller@0', 'default'):

I might have done something stupid; Now I need do stop, but I'll test again this evening.

Many thanks Mauro

On 1/13/20 1:45 PM, Stefan Roese wrote:

On 13.01.20 13:24, Mauro Condarelli wrote:

...

On 1/13/20 12:39 PM, Stefan Roese wrote:

...

Hi Mauro,

On 13.01.20 11:24, Mauro Condarelli wrote:

...

On 1/13/20 7:53 AM, Stefan Roese wrote:

...

Hi Mauro,

On 11.01.20 20:00, Mauro Condarelli wrote:

...

I managed to find ONE of the reasons why my ROM build didn't run: I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.

I see. This explains of course, why your board does not boot without any "preloader".

...

I wanted, nonetheless, be prepared for further mishaps, but I have some other problems (see below).

Are these issues now fixed? I scanned the discussion about the DEBUG UART on the list. Is this working for you now or do you have any other issues still? Did you successfully boot your new U-Boot from SPI NOR?

Yes and no :(

I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach  my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure).

Before looking into this in more depth (I actually do have problems sleeping though, so I might take a look at it later ;)), why don't you re-start with your defconfig by using the linkit defconfig file. If you are lucky, the LinkIt binary might even work for the VoCore2. Or what are the differences except the SoC type and WLAN? Its the same DDR2 config and the same UART. So it might get you pretty far - also with ROM based booting.

I will try it. Just to be on the safe side, could You attach a binary (or two: ROM and RAM) to the mail? If it works it would really give me a start base.

See below.

...

...

...

I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl@60 is not yet setup correctly?). This is the output I get from RAM-based u-boot:

<debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):

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 pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT:   Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC:   pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): 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(): =>

I don't have all these pinctrl issues on LinkIt. I suspect a config issue and / or dts issue. Please compare.

I will, but I was trying to say something different: Apparently the stock software tries to initialize uart2 pinctrl and it *seems* to succeed later in initialization. This *seems* to indicate explicit pin setup in board_early_init_f() is not strictly needed (we would lose only the first few lines even if we don't fix the error). I had a look to pinctrl-mt7628.c and it seems to do the right thing upon call to ('uart2_pins', 'default'), so anything after that *should* work even without low-level setup.

You might be correct here. So this explicit pin-muxing for UART2 is only needed when DEBUG UART is used. This makes the code a bit clearer and smaller. Lets keep it on our list to remove this, once all this is resolved.

...

...

...

ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required).

Yes. JTAG requires soldering IIRC.

...

The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course!

If I have to resort to that clumsy method, would be enough to put  "new" in  SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000

This is the TEXT_BASE for ROM based booting:

CONFIG_SYS_TEXT_BASE=0x9c000000

AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory region, the latter being uncached. I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some space for "old" (possibly crippled) u-boot doing initialization and then "jumping" to "new".

I see. Please give the LinkIt version a try first. This sounds easier (if it works) and more promising for my taste.

...

...

Please see configs/linkit-smart-7688_defconfig.

...

Did I forget something?

Not sure. I still think using the linkit port as a base for SPI NOR based booting would be a very good test at least. Do you see any problems with this approach (board / SoC differences)?

No. I see no troubles, for a basic startup. MMC would probably need some changes, but that can come later.

Yes. This test is just for basic very low level bootup checking. If this works, then you can use it as a basis to fine-tune your VoCore2 version from it by changing MMC etc support.

...

As said: I would like to try a prebuilt binary as first thing, so I can be sure I have no other problems (like gcc version or other local variations); then I would try to reproduce locally the equivalent binary with no changes and finally I would try to incorporate my specific needs. What do You think?

Please find attached the current mainline versions for LinkIt, one for RAM booting and one for ROM booting (in SPI NOR). I checked both version and they work fine on my LinkIt 7688 board:

U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) Model: LinkIt-Smart-7688 DRAM:  128 MiB Loading Environment from SPI Flash... SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB OK Net:   eth0: eth@10110000 Hit any key to stop autoboot:  0 =>

Thanks, Stefan

Hi Stefan, update, see below.

On 1/14/20 12:08 AM, Mauro Condarelli wrote:

Next episode of this telenovela:

I rebuilt u-boot for ROM at BC030000 (my code, very similar to LinkIt). I flashed it at 30000 in SPI NOR:

=> usb start; sf probe starting USB... Bus ehci@101c0000: pinctrl_select_state_full('ehci@101c0000', 'default'): 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 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load usb 0:1 85000000 u-boot.secondary 390089 bytes read in 18 ms (20.7 MiB/s) => sf update ${fileaddr} 30000 ${filesize} device 0 offset 0x30000, size 0x5f3c9 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s => reset

Restarted old u-boot and jumped to new:

U-Boot 1.1.3 (Apr 23 2017 - 14:59:01) VoCore2 > go bc030000 ## Starting application at 0xBC030000 ... board_debug_uart_init():

<debug_uart> System stopped here several minutes, enough for me to start writing this email, then it continued boot sequence:              board_debug_uart_init(): board_early_init_f():

Here is the first strange thing: apparently `board_debug_uart_init()` is called twice.

I am not 100% sure as code is full of `#ifdef`s, but it seems first time it's called in `arch/mips/cpu/start.S`, most likely in line 257 as I couldn't find traces of CONFIG_MIPS_INIT_STACK_IN_SRAM (besides `arch/mips/cpu/Kconfig:381` where is defined, defaults to `n` and none seems to touch anymore; second strange thing is I find no trace of it in `.config`)

This, again, does not add-up (third "strange thing") because I see nothing between calls to `debug_uart_init` (start.S:257) and `board_init_f` (start.S:264) that could trigger a ~5min delay (but I'm really out of my depth, here!) unless there's something in the `printascii()`itself (e.g.: loop at serial_mtk.c:449 blocks).

pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):

U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) Model: VoCore2 DRAM:  128 MiB pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT:   Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC:   pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): 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(): =>

Code, beside being targeted to ROM and with a different SYS_TEXT_BASE, is identical to what runs fine when started from RAM.

I also tried copying flash to ram:

=> cp.b bc030000 80010000 5f3c9 => go 80010000 ## Starting application at 0x80010000 ... board_debug_uart_init(): <debug_uart> [04010D08][04010D08] DDR Calibration DQS reg = 00008888 relocate_code Pointer at: 87f5c000

---

Watchdog Reset Occurred

---

... but this is almost expected because I relocated at another address without changing SYS_TEXT_BASE.

A further measurement shows booting u-boot from flash stops for almost 5 minutes (4m48s, using a manual stopwatch).

I sincerely have no idea where to bang my head :(

TiA Mauro

On 1/13/20 3:14 PM, Mauro Condarelli wrote:

...

Hi Stefan, unfortunately it does *not* work.

Ram based is ok, but rom  is just as silent as mine:

=> usb start; sf probe; starting USB... Bus ehci@101c0000: pinctrl_select_state_full('ehci@101c0000', 'default'): 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 pinctrl_select_state_full('spi@b00', 'default'): SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load usb 0:1 85000000 u-boot_linkit.bin-rom 455708 bytes read in 22 ms (19.8 MiB/s) => sf update ${fileaddr} 0 ${filesize} device 0 offset 0x0, size 0x6f41c 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s => reset resetting ... pinctrl_select_state_full('syscon-reboot', 'default'): pinctrl_select_state_full('system-controller@0', 'default'):

I might have done something stupid; Now I need do stop, but I'll test again this evening.

Many thanks Mauro

On 1/13/20 1:45 PM, Stefan Roese wrote:

...

On 13.01.20 13:24, Mauro Condarelli wrote:

...

On 1/13/20 12:39 PM, Stefan Roese wrote:

...

Hi Mauro,

On 13.01.20 11:24, Mauro Condarelli wrote:

...

On 1/13/20 7:53 AM, Stefan Roese wrote: > Hi Mauro, > > On 11.01.20 20:00, Mauro Condarelli wrote: >> I managed to find ONE of the reasons why my ROM build didn't run: >> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`. > I see. This explains of course, why your board does not boot without > any "preloader". > >> I wanted, nonetheless, be prepared for further mishaps, but >> I have some other problems (see below). > Are these issues now fixed? I scanned the discussion about the DEBUG > UART on the list. Is this working for you now or do you have any > other > issues still? Did you successfully boot your new U-Boot from SPI NOR? Yes and no :(

I fixed my RAM-based problems, but booting from SPI NOR still refuses to utter a single byte. I do attach  my defconfigs and my board.c for your reading pleasure (in case you have troubles getting asleep they should provide a good cure).

Before looking into this in more depth (I actually do have problems sleeping though, so I might take a look at it later ;)), why don't you re-start with your defconfig by using the linkit defconfig file. If you are lucky, the LinkIt binary might even work for the VoCore2. Or what are the differences except the SoC type and WLAN? Its the same DDR2 config and the same UART. So it might get you pretty far - also with ROM based booting.

I will try it. Just to be on the safe side, could You attach a binary (or two: ROM and RAM) to the mail? If it works it would really give me a start base.

See below.

...

...

...

I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c and it turns out system tries to setup pins for uart2, but fails (maybe because pinctrl@60 is not yet setup correctly?). This is the output I get from RAM-based u-boot:

<debug_uart> board_debug_uart_init(): board_early_init_f(): pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 pinctrl_select_state_full('clkctrl@0x2c', 'default'):

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 pinctrl_select_state_full('palmbus@10000000', 'default'): pinctrl_select_state_full('pinctrl@60', 'default'): pinctrl_select_state_full('pin_state', 'default'): pinctrl_select_state_full('uart2@e00', 'default'): pinctrl_select_state_full('uart2_pins', 'default'): pinctrl_select_state_full('clkctrl@0x2c', 'default'): pinctrl_select_state_full('watchdog@100', 'default'): WDT:   Started with servicing (60s timeout) board_early_init_r(): arch_early_init_r(): MMC:   pinctrl_select_state_full('mmc@10130000', 'default'): pinctrl_select_state_full('sd_iot_mode', 'default'): pinctrl_select_state_full('clk48m@0', 'default'): 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(): =>

I don't have all these pinctrl issues on LinkIt. I suspect a config issue and / or dts issue. Please compare.

I will, but I was trying to say something different: Apparently the stock software tries to initialize uart2 pinctrl and it *seems* to succeed later in initialization. This *seems* to indicate explicit pin setup in board_early_init_f() is not strictly needed (we would lose only the first few lines even if we don't fix the error). I had a look to pinctrl-mt7628.c and it seems to do the right thing upon call to ('uart2_pins', 'default'), so anything after that *should* work even without low-level setup.

You might be correct here. So this explicit pin-muxing for UART2 is only needed when DEBUG UART is used. This makes the code a bit clearer and smaller. Lets keep it on our list to remove this, once all this is resolved.

...

...

...

ROM-based u-boot, as said, does not print *anything*, not even garbage. I'm beginning to suspect I have some mishap with start address or similar. I have absolutely no idea how to debug this without a JTAG probe (which I don't have and would be non-trivial to get working; soldering required).

Yes. JTAG requires soldering IIRC.

...

The only idea I currently have is to modify my "old" u-boot to do initialization and then jump to beginning of "new" u-boot. If I can make it work in an automatic way I can try removing initialization steps till I find the "culprit". Any better idea would be welcome, of course!

If I have to resort to that clumsy method, would be enough to put  "new" in  SPI NOR (of course at an higher address, e.g.: 30000 as "old" is only 183272 bytes long) and jump to the first location? I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc030000

This is the TEXT_BASE for ROM based booting:

CONFIG_SYS_TEXT_BASE=0x9c000000

AFAIK 0x9c000000 and 0xbc000000 map to the same (unmapped) memory region, the latter being uncached. I proposed 0xbc030000 (but it could be 0x9c030000) as base to leave some space for "old" (possibly crippled) u-boot doing initialization and then "jumping" to "new".

I see. Please give the LinkIt version a try first. This sounds easier (if it works) and more promising for my taste.

...

...

Please see configs/linkit-smart-7688_defconfig.

...

Did I forget something?

Not sure. I still think using the linkit port as a base for SPI NOR based booting would be a very good test at least. Do you see any problems with this approach (board / SoC differences)?

No. I see no troubles, for a basic startup. MMC would probably need some changes, but that can come later.

Yes. This test is just for basic very low level bootup checking. If this works, then you can use it as a basis to fine-tune your VoCore2 version from it by changing MMC etc support.

...

As said: I would like to try a prebuilt binary as first thing, so I can be sure I have no other problems (like gcc version or other local variations); then I would try to reproduce locally the equivalent binary with no changes and finally I would try to incorporate my specific needs. What do You think?

Please find attached the current mainline versions for LinkIt, one for RAM booting and one for ROM booting (in SPI NOR). I checked both version and they work fine on my LinkIt 7688 board:

U-Boot 2020.01-00473-g88366b96ee (Jan 13 2020 - 13:37:15 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr) Model: LinkIt-Smart-7688 DRAM:  128 MiB Loading Environment from SPI Flash... SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB OK Net:   eth0: eth@10110000 Hit any key to stop autoboot:  0 =>

Thanks, Stefan

Regards Mauro

Hi Mauro,

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.

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?

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?

Thanks, Stefan

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.

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.

...

...

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.

...

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 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}

Thanks, Stefan

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

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

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 ;(

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? I assume difference in the very last word (actually the first word out) is significant.

As said there could be differences in Bootstrapping pins latching. I will review that after lunch...

Thanks, Stefan

Thanks, so far... ;) Mauro

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

On 1/15/20 5:20 PM, Stefan Roese wrote:

On 15.01.20 16:55, Mauro Condarelli wrote:

<snip>

===8<------

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.

My SPI NOR is 16 MiB, so I cannot access anything beyond that ;)

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".

That wouldn't be easy as it's a SMD resistor soldered directly on the Module. Let's keep that as "last resort".   ===8<------

...

...

...

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 was trying to say that, in my "secondary u-boot" attempts, where I start from "paleolithic" and then do a "go <addr>" I need to put the secondary at the same address specified in SYS_TEXT_BASE. I mean: if I want to boot directly from new then     SYS_TEXT_BASE = 0x9c000000     flash at start of SPI NOR     go 9c000000 else if I want to start "secondary" then     SYS_TEXT_BASE = 0x9c030000     flash at offset 30000 in SPI NOR     go 9c030000 Any other combination does not work (i.e.: I cannot flash and run at start an u-boot compiled with SYS_TEXT_BASE = 0x9c030000 and vice versa).

Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently it is visible in menuconfig only for ARM; am I missing something?

===8<------

I do have a led I can use for crude signalling, but I'm not really familiar with mips Assembly. Can You share the code to turn it on? (it is connected to GPIO44/WLED(pin144).

Thanks, Stefan

TiA! Mauro