search

xobs / fernly

Fernvale research OS
BSD 2-Clause "Simplified" License
143 stars 52 forks source link

Loader freezes while writing stage2 #12

Open jacobrosenthal opened 9 years ago

jacobrosenthal commented 9 years ago

As of 1023337c61bba7a74d4537010925f0c468241675 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 commented 9 years ago

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

As of 1023337 https://github.com/xobs/fernly/commit/1023337c61bba7a74d4537010925f0c468241675 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 commented 9 years ago

Same.

pfalcon commented 9 years ago

FYI, with my hardware (a typical mt6260 smartwatch), with current master (i.e. after https://github.com/xobs/fernly/commit/1dc8e8c57315adbbb3c2a87311359505913d0133) 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Something is definitely racy there.

pfalcon commented 9 years ago

@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 commented 9 years ago

@pfalcon Yes, interrupts are disabled.

nieldk commented 3 years ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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