UART question: Rescue Loader / UART loopback switch - page 5 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 2 3 4 [5] 6   Go Down

UART question: Rescue Loader / UART loopback switch

  • 51 Replies
  • 23111 Views
*

Offline Ant

  • *****
  • 509
Re: UART question: Rescue Loader / UART loopback switch
« Reply #40 on: 19 / November / 2017, 06:47:12 »
Advertisements
There are some flags in RAM checked by bootloader during restart. For example it used for firmware update. You can play with them to force execution of your code.
Logged
*

Offline hardlock

  • *
  • 35
Re: UART question: Rescue Loader / UART loopback switch
« Reply #41 on: 19 / November / 2017, 06:56:45 »
Quote from: Ant on 19 / November / 2017, 06:47:12
There are some flags in RAM checked by bootloader during restart. For example it used for firmware update. You can play with them to force execution of your code.
I will try to find it, but can you provide some example addresses for any camera?

please clarify, what do mean by 'restart'.  A jump to the bootloader (starting sector of eeprom)  boot or main code (start + 128K)?
looks like i should read something from vast knowlegde base of the CHDK project.




Logged
*

Offline Ant

  • *****
  • 509
Re: UART question: Rescue Loader / UART loopback switch
« Reply #42 on: 19 / November / 2017, 07:05:51 »
For M3 I've used this to redirect console messages from main firmware.

Quote
please clarify, what do mean by 'restart'
I mean "q              Quit ( =Reset )".

I also recommed you to execute your bootloader code in QEMU. Just replace M3's ROM dump by yours.
Logged
*

Offline Ant

  • *****
  • 509
Re: UART question: Rescue Loader / UART loopback switch
« Reply #43 on: 19 / November / 2017, 15:44:30 »
Quote from: Ant on 19 / November / 2017, 06:47:12
There are some flags in RAM checked by bootloader during restart. For example it used for firmware update. You can play with them to force execution of your code.
Maybe I was wrong and these flags are used by firmware updater(name of FI2 file) and by main firmware (0x12345678 signature).

So you need to get all startup messages. Maybe bus pirate don't recieve them while sending "#". Try to send "#" manually after pressing "q" in debug shell.
Logged
*

Offline hardlock

  • *
  • 35
Re: UART question: Rescue Loader / UART loopback switch
« Reply #44 on: 19 / November / 2017, 22:26:53 »
Quote from: Ant on 19 / November / 2017, 15:44:30
So you need to get all startup messages. Maybe bus pirate don't recieve them while sending "#". Try to send "#" manually after pressing "q" in debug shell.

restart via 'q' does not show '#' on the console.  it jumps to FC000000 ( not FC000000+1 ) and hangs.  (as far as i undestand, it  tries to execute thumb code as a 32bit ARM)
Logged
*

Offline Ant

  • *****
  • 509
Re: UART question: Rescue Loader / UART loopback switch
« Reply #45 on: 20 / November / 2017, 07:22:08 »
Quote from: hardlock on 19 / November / 2017, 22:26:53
restart via 'q' does not show '#' on the console.  it jumps to FC000000 ( not FC000000+1 ) and hangs.  (as far as i undestand, it  tries to execute thumb code as a 32bit ARM)

It doesn't work in QEMU too. Maybe this is because FC000000 contains reset vector, not executable code. If you want to execute your code from debug shell you can modify in stack the return address of "o" command by itself.
Emulating EOS M3 in QEMU I've successfully executed my code using command "o 3ea8 8001" (8000+1 is the address of your code).
Code: [Select]
Set default DRAM parameter
#UUART loopback switch OFF...
Rescue Loader

---------------------------
DISKBOOT.BIN is started.
--- DISKBOOT.BIN start ABORT!!! ---

>> debug shell startted <<
>> o 3ea8 8001
00003EA8 <- 8001

DRYOS version 2.3, release #0055+p6
Copyright (C) 1997-2013 by CANON Inc.

But it's better to use encoded DISKBOOT.BIN. Read your bootloader's messages from the beginning to understand why it doesn't start.
« Last Edit: 20 / November / 2017, 07:32:08 by Ant »
Logged
*

Offline hardlock

  • *
  • 35
Re: UART question: Rescue Loader / UART loopback switch
« Reply #46 on: 23 / November / 2017, 00:36:23 »
Quote from: Ant on 20 / November / 2017, 07:22:08
But it's better to use encoded DISKBOOT.BIN. Read your bootloader's messages from the beginning to understand why it doesn't start.

i will try to experiment and i will report back.
Logged
*

Offline hardlock

  • *
  • 35
Re: UART question: Rescue Loader / UART loopback switch
« Reply #47 on: 23 / November / 2017, 13:07:46 »
i am practicing reading files to memory ('f' command of the debug shell uses the same procedure that  loads diskboot.bin ) and I see some weird behaviour. The addresses 0x8000 became a copy of 0x40008000 only once or until  something is being written to them.

it looks like an MMU copy-on-write behavior for me.  I think I need to read something about ARM systems memory mapping.  I know nothing about it at the moment.

just in case, I have tried to flush the cpu cache with accessing many addresses via "v 8000 8000 9999999" command, but it does not help. looks like it is not a case of a CPU cache. 


>> d 40008000 20
40008000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................
40008010:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................
>> f 40008000 BOOTBOOT.BIN
>>  d 40008000 20
40008000:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
40008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>> d 8000 20
00008000:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
00008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>> o 8000 1111
00008000 <- 1111
>> d 8000 20
00008000:  11 11 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ....XXXXXXXXXXXX
00008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>> d 40008000 20
40008000:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
40008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>>
>>  f 40008000 BOOTBOOT.BIN
>>  d 40008000 20
40008000:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
40008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>>  d 8000 20
00008000:  11 11 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ....XXXXXXXXXXXX
00008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>> o 40008000 2222
40008000 <- 2222
>> d 40008000 20
40008000:  22 22 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ""..XXXXXXXXXXXX
40008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>>  d 8000 20
00008000:  11 11 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ....XXXXXXXXXXXX
00008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>>
>> v 8000 8000 9999999
>> d 8000 20
00008000:  11 11 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ....XXXXXXXXXXXX
00008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
>> d 40008000 20
40008000:  22 22 00 00 58 58 58 58 58 58 58 58 58 58 58 58     ""..XXXXXXXXXXXX
40008010:  58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58     XXXXXXXXXXXXXXXX
Logged
*

Offline hardlock

  • *
  • 35
Re: UART question: Rescue Loader / UART loopback switch
« Reply #48 on: 23 / November / 2017, 13:38:31 »
i see the situation as folllows:
if I access the address 0x8000 before any file reading (even if i just _read_ values "d 8000 20") then mapping  0x40008000 -> 0x8000 disappears.
Logged
*

Offline Ant

  • *****
  • 509
Re: UART question: Rescue Loader / UART loopback switch
« Reply #49 on: 23 / November / 2017, 14:07:41 »
Quote
it looks like an MMU copy-on-write behavior for me.
ARM Cortex R4 has no MMU.

Quote
if I access the address 0x8000 before any file reading (even if i just _read_ values "d 8000 20") then mapping  0x40008000 -> 0x8000 disappears.
This is because of cache. 0x40000000 bit means uncahed memory...
« Last Edit: 23 / November / 2017, 14:11:12 by Ant »
Logged
Pages: 1 2 3 4 [5] 6   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal