Loader freezes while writing stage2

[jacobrosenthal]

As of 1023337 I can't get into shell anymore. My hardware claims to be EVT1-B

build/fernly-usb-loader /dev/cu.usbmodem1410 build/usb-loader.bin build/firmware.bin
Setting serial port parameters... Ok
Initiating communication... Ok
Getting hardware version... 0xca00
Getting chip ID... 0x6260
Getting boot config (low)... 0x0000
Getting boot config (high)... 0x0000
Getting hardware subcode... 0x8000
Getting hardware version (again)... 0xca00
Getting chip firmware version... 0x0000
Getting security version... v 5
Enabling security (?!)... Ok
Reading ME... 00000000 6e a8 9a 5e 22 33 e5 43  f9 33 3b 04 11 b5 4b 15  |n..^"3.C.3;...K.|
Disabling WDT... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0004
Reading RTC Power Key 1 (0xa0710050)... 0x79ff
Reading RTC Power Key 2 (0xa0710054)... 0xbfff
Setting seconds... Ok
Disabling alarm IRQs... Ok
Disabling RTC IRQ interval... Ok
Enabling transfers from core to RTC... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0004
Getting security configuration... None.
Getting PSRAM mapping... 0x0000
Disabling PSRAM -> ROM remapping... Ok
Checking PSRAM mapping... 0x0002
Checking on PSRAM mapping again... 0x0002
Updating PSRAM mapping again for some reason... Ok
Reading some fuses... 0x00000000
Enabling UART... 0x0000
Loading Fernly USB loader... checksum matches 0x276e Ok
Executing Ferly USB loader... Ok
Waiting for Fernly USB loader banner... Ok
Writing stage 2... 20112 bytes... 

[xobs]

On 20/02/2015 11:34, Jacob Rosenthal wrote:

As of 1023337
1023337
I can't get into shell anymore. My hardware claims to be EVT1-B

|build/fernly-usb-loader /dev/cu.usbmodem1410 build/usb-loader.bin build/firmware.bin
Setting serial port parameters... Ok
Initiating communication... Ok
Getting hardware version... 0xca00
Getting chip ID... 0x6260
Getting boot config (low)... 0x0000
Getting boot config (high)... 0x0000
Getting hardware subcode... 0x8000
Getting hardware version (again)... 0xca00
Getting chip firmware version... 0x0000
Getting security version... v 5
Enabling security (?!)... Ok
Reading ME... 00000000 6e a8 9a 5e 22 33 e5 43 f9 33 3b 04 11 b5 4b 15 |n..^"3.C.3;...K.|
Disabling WDT... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0004
Reading RTC Power Key 1 (0xa0710050)... 0x79ff
Reading RTC Power Key 2 (0xa0710054)... 0xbfff
Setting seconds... Ok
Disabling alarm IRQs... Ok
Disabling RTC IRQ interval... Ok
Enabling transfers from core to RTC... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0004
Getting security configuration... None.
Getting PSRAM mapping... 0x0000
Disabling PSRAM -> ROM remapping... Ok
Checking PSRAM mapping... 0x0002
Checking on PSRAM mapping again... 0x0002
Updating PSRAM mapping again for some reason... Ok
Reading some fuses... 0x00000000
Enabling UART... 0x0000
Loading Fernly USB loader... checksum matches 0x276e Ok
Executing Ferly USB loader... Ok
Waiting for Fernly USB loader banner... Ok
Writing stage 2... 20112 bytes...
|
Hi Jacob,

What if you change send_max to something smaller? Even something as low
as 1.

Sean

[jacobrosenthal]

Same.

[pfalcon]

FYI, with my hardware (a typical mt6260 smartwatch), with current master (i.e. after 1dc8e8c) I was able to get into shell ~ dozen times, and in that commit redefined FIFO_MAX back to 32, it booted and were able to run dozen of commands.

My boot dump (obvious difference from the dump above is "hardware version... 0xcb00"):

Getting hardware version... 0xcb00
Getting chip ID... 0x6260
Getting boot config (low)... 0x0000
Getting boot config (high)... 0x0000
Getting hardware subcode... 0x8000
Getting hardware version (again)... 0xcb00
Getting chip firmware version... 0x0000
Getting security version... v 5
Enabling security (?!)... Ok
Reading ME... 00000000 05 55 11 47 ea 79 2f 50  44 5e 37 21 fb c4 8a fa  |.U.G.y/PD^7!....|
Disabling WDT... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0000
Reading RTC Power Key 1 (0xa0710050)... 0xa357
Reading RTC Power Key 2 (0xa0710054)... 0x67d2
Setting seconds... Ok
Disabling alarm IRQs... Ok
Disabling RTC IRQ interval... Ok
Enabling transfers from core to RTC... Ok
Reading RTC Baseband Power Up (0xa0710000)... 0x0000
Getting security configuration... None.
Getting PSRAM mapping... 0x0000
Disabling PSRAM -> ROM remapping... Ok
Checking PSRAM mapping... 0x0002
Checking on PSRAM mapping again... 0x0002
Updating PSRAM mapping again for some reason... Ok
Reading some fuses... 0x00000000
Enabling UART... 0x0000
Loading Fernly USB loader... checksum matches 0x2761 Ok
Executing Ferly USB loader... Ok
Waiting for Fernly USB loader banner... Ok
Writing stage 2... 20468 bytes...  20468 /  20468 Ok
Launching program...
Reset exception
Registers:
CPSR: 600000d3
SPSR: 00000010
R0:   00000000
R1:   00000008
R2:   00000012
R3:   7000aaf4
R4:   70002040
R5:   000008f4
R6:   00000000
R7:   00000000
R8:   00000000
R9:   00000000
R10:  00000000
FP:   00000000
IP:   00000008
SP:   7000cef4
PC:   7000ade4


Fernly shell
Initializing LCD... Ok
Width: 240  Height: 320
fernly>

[pfalcon]

I bragged too early. With FIFO_MAX=32, I get 100% lockup on running "keypad" command (funnily, lockup happens immediately after pressing Enter key - I don't even see carriage return "printed" by fernly).

[thesourcerer8]

The keypad is doing a busyloop, yes. You have to press the # key (bottom right) on the keypad to return to normal fernly command shell.

[pfalcon]

My comment above reports issue with USB communication, at best output data being lost, at worst, lockup. The fact that it happens with "keypad" command is random, like usually happens with race conditions.

[xobs]

Something is definitely racy there.

[pfalcon]

@xobs: But to clarify, the whole fernly runs with interrupts disabled, and instead just polls irq status bits when needed, right? (I.e. we can exclude races due to irq's.)

[xobs]

@pfalcon Yes, interrupts are disabled.

[nieldk]

Hmm I had this issue with mtk6261 in a china GPS, couldnt finish stage two. I know this repo doesnt support that, so I am using the one from https://github.com/isogashii/fernly which supports the 6261 supposedly.
WHat I did do, to make it work, was to change line 18 in fernly-usb-loader.c from #define STAGE_2_WRITE_ALL_AT_ONCE 1 to #define STAGE_2_WRITE_ALL_AT_ONCE 0
That made stage2 finish and i am able to enter shell.

[MLXProjects]

@nieldk I'm also trying to get shell on a 6261 device, mine gets stuck on waiting for shell (using same repo/branch as you).
Did you also face this issue? I'm able to boot fernly and even dump the ROM using flashrom, but for some reason it doesn't like entering shell mode...

[nieldk]

@nieldk I'm also trying to get shell on a 6261 device, mine gets stuck on waiting for shell (using same repo/branch as you).

Did you also face this issue? I'm able to boot fernly and even dump the ROM using flashrom, but for some reason it doesn't like entering shell mode...

Did you read my comment? I managed to get it making that small change i mentioned

[MLXProjects]

Did you read my comment? I managed to get it making that small change i mentioned

Well, your issue was different (getting stuck at writing stage 2) but anyway I've tried that before asking, didn't help :P
That's why I was asking for this particular issue, I hope to find something else to do