Re: Debugging VoCore2 ROM Startup
Hi Mauro, On 15.01.20 18:25, Mauro Condarelli wrote: Note: I assumed u-boot-mtmips.bin is linked at 9c00, 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 0x9c00. Can You elaborate, please? Each image generated to boot from SPI NOR needs to be linked to 9c00. 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 3 a u-boot that has been compiled with SYS_TEXT_BASE = 0x9c00 it will not start with "go 9c03" I need to rebuild with SYS_TEXT_BASE = 0x9c03. 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 " 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 = 0x9c00 flash at start of SPI NOR go 9c00 else if I want to start "secondary" then SYS_TEXT_BASE = 0x9c03 flash at offset 3 in SPI NOR go 9c03 Any other combination does not work (i.e.: I cannot flash and run at start an u-boot compiled with SYS_TEXT_BASE = 0x9c03 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? I can change it for my LinkIt target via "make menuconfig". Just search for it by entering "/" in "make menuconfig" and it should show up there. ===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). i don't remember but it might be the case. Here the code snippet that I used at that time. Perhaps it helps: +#if 0 // test-only: WLAN LED on +#define RALINK_SYSCTL_BASE 0xB000 + // GPIO mode + li t0, RALINK_SYSCTL_BASE + 0x64 + li t1, 0x05540551 + sw t1, 0(t0) + + // GPIO direction + li t0, RALINK_SYSCTL_BASE + 0x604 + li t1, 0x1000 + sw t1, 0(t0) + + // GPIO value + li t0, RALINK_SYSCTL_BASE + 0x624 + li t1, 0x0002f5f + sw t1, 0(t0) +#endif Thanks, Stefan
Re: Debugging VoCore2 ROM Startup
On 1/15/20 5:20 PM, Stefan Roese wrote: > On 15.01.20 16:55, Mauro Condarelli wrote: > > ===8<-- > in particular: >> >> b010: 00065144 >> System Configuration Register 0 -> 0110 0101 0001 0100 >> 0100 >> 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 9c00, 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 0x9c00. >> Can You elaborate, please? > > Each image generated to boot from SPI NOR needs to be linked to 9c00. > 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 3 a u-boot that has been compiled >> with SYS_TEXT_BASE = 0x9c00 it will not start with "go 9c03" >> I need to rebuild with SYS_TEXT_BASE = 0x9c03. > > 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 " 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 = 0x9c00 flash at start of SPI NOR go 9c00 else if I want to start "secondary" then SYS_TEXT_BASE = 0x9c03 flash at offset 3 in SPI NOR go 9c03 Any other combination does not work (i.e.: I cannot flash and run at start an u-boot compiled with SYS_TEXT_BASE = 0x9c03 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
Re: Debugging VoCore2 ROM Startup
On 15.01.20 16:55, Mauro Condarelli wrote:
=> md b000
b000: 3637544d 20203832 0010 00010102 MT7628
b010: 00156156 02605500 Va...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: ffc0 0400 c0030004 00fe00ff
b040: 0001
b050: 0810
b060: 50050404 05550551 ...PQ.U.
This is my register dump, for reference:
VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102 MT7628
b010: 00144144 02605500 DA...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
b040: 0001
b050: 0810
b060: 5505040c 05540555 ...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 b000
b000: 3637544d 20203832 0001 00010102 MT7628
b010: 00065144 02605500 DQ...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
b040: 0001
b050: 0810
b060: 5505040c 05540555 ...UU.T.
in particular:
b010: 00065144
System Configuration Register 0 -> 0110 0101 0001 0100 0100
TEST_CODE : None
000 Reserved
0 0110 0101 BS_SHADOW : ???
000 Rseserved
1 DBG_JTAG_MODE1: Normal Boot-up
0 TEST_MODE_1 : ???
1 XTAL_FREQ_SEL1: 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_TYPE0: 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 8001 u-boot-ram.bin; go 8001
(Re)start USB...
USB0: Mediatek/Ralink USB EHCI
Register 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 0x8001 ...
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@1013', 'default'):
mmc@1013: 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 8500 u-boot-mtmips.bin
starting USB...
Bus ehci@101c: USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage
Re: Debugging VoCore2 ROM Startup
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):
b008: 0001
E-Fuse Configuration is not pristine, but I don't know what it my
mean.
b010: 0044 D...
System Configuration Register 0 -> 0001 0001 0001 0001 1000
1000
>>>
>>> Not correct:
>>>
>>> System Configuration Register 0 -> 0001 0001 0001 0001 0100
>>> 0100
>> Right.
>> Shame on me.
>>
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 b000
>>> b000: 3637544d 20203832 0010 00010102 MT7628
>>> b010: 00156156 02605500 Va...U`.
>>> b020: 1024 0071 0020100c ..$.q. .
>>> b030: ffc0 0400 c0030004 00fe00ff
>>> b040: 0001
>>> b050: 0810
>>> b060: 50050404 05550551 ...PQ.U.
>> This is my register dump, for reference:
>> VoCore2 > md b000
>> b000: 3637544d 20203832 0001 00010102 MT7628
>> b010: 00144144 02605500 DA...U`.
>> b020: 1024 0071 0020100c ..$.q. .
>> b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
>> b040: 0001
>> b050: 0810
>> b060: 5505040c 05540555 ...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 b000
b000: 3637544d 20203832 0001 00010102 MT7628
b010: 00065144 02605500 DQ...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
b040: 0001
b050: 0810
b060: 5505040c 05540555 ...UU.T.
in particular:
b010: 00065144
System Configuration Register 0 -> 0110 0101 0001 0100 0100
TEST_CODE : None
000 Reserved
0 0110 0101 BS_SHADOW : ???
000 Rseserved
1 DBG_JTAG_MODE1: Normal Boot-up
0 TEST_MODE_1 : ???
1 XTAL_FREQ_SEL1: 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_TYPE0: 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:
Re: Debugging VoCore2 ROM Startup
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):
b008: 0001
E-Fuse Configuration is not pristine, but I don't know what it my mean.
b010: 0044 D...
System Configuration Register 0 -> 0001 0001 0001 0001 1000
1000
Not correct:
System Configuration Register 0 -> 0001 0001 0001 0001 0100 0100
Right.
Shame on me.
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 b000
b000: 3637544d 20203832 0010 00010102 MT7628
b010: 00156156 02605500 Va...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: ffc0 0400 c0030004 00fe00ff
b040: 0001
b050: 0810
b060: 50050404 05550551 ...PQ.U.
This is my register dump, for reference:
VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102 MT7628
b010: 00144144 02605500 DA...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
b040: 0001
b050: 0810
b060: 5505040c 05540555 ...UU.T.
Okay, thanks. We can compare this now in depth.
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. :-(
Here's transcript:
VoCore2 > usb reset; fatload usb 0 8001 u-boot-ram.bin; go 8001
(Re)start USB...
USB0: Mediatek/Ralink USB EHCI
Register 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 0x8001 ...
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@1013', 'default'):
mmc@1013: 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 8500 u-boot-mtmips.bin
starting USB...
Bus ehci@101c: USB EHCI 1.00
scanning bus ehci@101c 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
Re: Debugging VoCore2 ROM Startup
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):
>>
>> b008: 0001
>> E-Fuse Configuration is not pristine, but I don't know what it my mean.
>>
>> b010: 0044 D...
>> System Configuration Register 0 -> 0001 0001 0001 0001 1000
>> 1000
>
> Not correct:
>
> System Configuration Register 0 -> 0001 0001 0001 0001 0100 0100
Right.
Shame on me.
>> 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 b000
> b000: 3637544d 20203832 0010 00010102 MT7628
> b010: 00156156 02605500 Va...U`.
> b020: 1024 0071 0020100c ..$.q. .
> b030: ffc0 0400 c0030004 00fe00ff
> b040: 0001
> b050: 0810
> b060: 50050404 05550551 ...PQ.U.
This is my register dump, for reference:
VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102 MT7628
b010: 00144144 02605500 DA...U`.
b020: 1024 0071 0020100c ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff ..@.
b040: 0001
b050: 0810
b060: 5505040c 05540555 ...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 8001 u-boot-ram.bin; go 8001
(Re)start USB...
USB0: Mediatek/Ralink USB EHCI
Register 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 0x8001 ...
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@1013', 'default'):
mmc@1013: 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 8500 u-boot-mtmips.bin
starting USB...
Bus ehci@101c: USB EHCI 1.00
scanning bus ehci@101c 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
Re: Debugging VoCore2 ROM Startup
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): b008: 0001 E-Fuse Configuration is not pristine, but I don't know what it my mean. b010: 0044 D... System Configuration Register 0 -> 0001 0001 0001 0001 1000 1000 Not correct: System Configuration Register 0 -> 0001 0001 0001 0001 0100 0100 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 b000 b000: 3637544d 20203832 0010 00010102MT7628 b010: 00156156 02605500 Va...U`. b020: 1024 0071 0020100c..$.q. . b030: ffc0 0400 c0030004 00fe00ff b040: 0001 b050: 0810 b060: 50050404 05550551 ...PQ.U. 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) 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. :) Thanks, Stefan
Re: Debugging VoCore2 ROM Startup
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 0x1060
#define MIPS_KSEG1_START 0xA000
uint32_t v, *a;
a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
v = *a;
v &= 0xF3FF;
v |= 0x000C;
*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 b060 1
>>> b060: 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 b060 1
>> b060: 5505040c ...U
>> VoCore2 > mm b060
>> b060: 5505040c ? 55050404
>>
>> 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 b060 5505040c�
>
>
> 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):
b008: 0001
E-Fuse Configuration is not pristine, but I don't know what it my mean.
b010: 0044 D...
System Configuration Register 0 -> 0001 0001 0001 0001 1000 1000
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 = 0x9c00
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 8001 u-boot-ram.bin; go 8001
>> usb start; sf probe;
>> load usb 0:1 8500 u-boot-rom.bin; sf update ${fileaddr} u-boot
>>
Re: Debugging VoCore2 ROM Startup
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 0x1060
#define MIPS_KSEG1_START 0xA000
uint32_t v, *a;
a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
v = *a;
v &= 0xF3FF;
v |= 0x000C;
*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 b060 1
b060: 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 b060 1
b060: 5505040c ...U
VoCore2 > mm b060
b060: 5505040c ? 55050404
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 b060 5505040c�
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 = 0x9c00
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 8001 u-boot-ram.bin; go 8001
usb start; sf probe;
load usb 0:1 8500 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
- 0x-0x0100 : "nor0"
- 0x-0x0007e000 : "u-boot"
- 0x0007e000-0x0007f000 : "env"
- 0x0007f000-0x0008 : "factory"
- 0x0008-0x0032 : "kernel"
- 0x0032-0x0100 : "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
Re: Debugging VoCore2 ROM Startup
HI Stefan,
On 1/15/20 8:25 AM, Stefan Roese wrote:
> 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 0x1060
>> #define MIPS_KSEG1_START 0xA000
>>
>> uint32_t v, *a;
>> a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
>> v = *a;
>> v &= 0xF3FF;
>> v |= 0x000C;
>> *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 b060 1
> b060: 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 b060 1
b060: 5505040c ...U
VoCore2 > mm b060
b060: 5505040c ? 55050404
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)?
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 = 0x9c00
>>
>> 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.
> 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.
I am using the new, RAM-based U-Boot to flash.
Actual sequence is:
usb reset; fatload usb 0 8001 u-boot-ram.bin; go 8001
usb start; sf probe;
load usb 0:1 8500 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
- 0x-0x0100 : "nor0"
- 0x-0x0007e000 : "u-boot"
- 0x0007e000-0x0007f000 : "env"
- 0x0007f000-0x0008 : "factory"
- 0x0008-0x0032 : "kernel"
- 0x0032-0x0100 : "filesystem"
Equivalent sequences work correctly to flash kernel and (recovery)
filesystem.
> Thanks,
> Stefan
Many thanks for Your patience...
Mauro
Re: Debugging VoCore2 ROM Startup
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 0x1060 #define MIPS_KSEG1_START 0xA000 uint32_t v, *a; a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE); v = *a; v &= 0xF3FF; v |= 0x000C; *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 b060 1 b060: 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 = 0x9c00 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
Debugging VoCore2 ROM Startup (was: How to debug HW startup?)
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 0x1060
#define MIPS_KSEG1_START 0xA000
uint32_t v, *a;
a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
v = *a;
v &= 0xF3FF;
v |= 0x000C;
*a = v;
It is unclear to me how Linkit port could work.
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 = 0x9c00
still refuses to display anything on serial; I assume some other
initialization is missing, but that will be another fight.
Any insight welcome.
Regards
Mauro
On 1/14/20 12:08 AM, Mauro Condarelli wrote:
> Next episode of this telenovela:
>
> I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
> I flashed it at 3 in SPI NOR:
>
> => usb start; sf probe
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c 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 8500 u-boot.secondary
> 390089 bytes read in 18 ms (20.7 MiB/s)
> => sf update ${fileaddr} 3 ${filesize}
> device 0 offset 0x3, 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 bc03
> ## Starting application at 0xBC03 ...
> board_debug_uart_init():
>
> 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():
> pinctrl_select_state_full('palmbus@1000', '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@1000', '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@1013', 'default'):
> pinctrl_select_state_full('sd_iot_mode', 'default'):
> pinctrl_select_state_full('clk48m@0', 'default'):
> pinctrl_select_state_full('mmc@1013', 'default'):
> mmc@1013: 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 bc03 8001 5f3c9
> => go 8001
> ## Starting application at 0x8001 ...
> board_debug_uart_init():
> [04010D08][04010D08]
> DDR Calibration DQS reg =
> 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@101c: pinctrl_select_state_full('ehci@101c', 'default'):
>> USB EHCI 1.00
>> scanning bus ehci@101c 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 8500 u-boot_linkit.bin-rom
>> 455708 bytes read in 22 ms (19.8 MiB/s)
>> => sf update ${fileaddr} 0 ${filesize}
>>
