EOS M3 porting - page 10 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 71   Go Down

EOS M3 porting

  • 709 Replies
  • 326373 Views
*

Offline HujaWianki

  • *
  • 13
Re: EOS M3 porting
« Reply #90 on: 17 / July / 2016, 06:49:58 »
Advertisements
Hello Ant,
Quote
”Just copy EOS_M3.FI2 to SD card and start update from camera's menu.
Have you already tried to downgrade the firmware in this way?
BR, Wianki
Logged
*

Offline Ant

  • *****
  • 508
Re: EOS M3 porting
« Reply #91 on: 17 / July / 2016, 06:54:32 »
Yes. I upgraded to 1.1.0, made dump and "upgraded" back to 1.0.1 using firmware update menu.
Logged
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: EOS M3 porting
« Reply #92 on: 17 / July / 2016, 07:01:14 »
Understood. So you are able to run code from diskboot.bin, but you don't have access to file I/O. You can, however, use LED blinks and TIO messages, correct?

FC0F84FC: there appears to be a 8MB ROM at FB800000, besides the one at FC000000. I'd like a copy of this one, but it's probably best to ask another EOS M3 user. Could be useful for QEMU.

Code: [Select]
// handles both ROMs, even with a single call; block size is 0x2000
// returns 0 on success, 5 = out of range, odd values = other errors
FC0F83CA int erase_flash(uint32_t addr, uint32_t size)

// similar
FC0F8362 int write_flash(uint32_t rom_addr, uint32_t ram_addr, uint32_t size)

They are used in many places in the firmware, for example:
Code: [Select]
print "== Hivshd_VOffset Write ==\r"
if erase_flash(hivshd_rom_addr, hivshd_size)) & 1:
    print "\r\nHivshd Voffset EraseError"
    return
print "Hivshd_VOffset  ROM %p RAM %p ( Size %ld )\r" % (hivshd_rom_addr, hivshd_ram_addr, hivshd_size)
    if write_flash(hivshd_rom_addr, hivshd_ram_addr, hivshd_size) & 1:
    print "\r\nHivshd VOffset WriteError"
    return

Don't rush to call them; I think it's best to play with them in QEMU, then experiment on an unused area of the ROM.

Warning: these functions can be abused, so @moderators, feel free to edit them out.
Logged
*

Offline Ant

  • *****
  • 508
Re: EOS M3 porting
« Reply #93 on: 17 / July / 2016, 07:58:13 »
Quote from: a1ex on 17 / July / 2016, 07:01:14
You can, however, use LED blinks and TIO messages, correct?
I did not try file IO and TIO messages. I suspect that they should be initialised before using.

About QEMU:
I did not get GUI working becouse GUISrv_StartGUISystem  (FC1454C8) stops somewhere around FC302400. Did you read my PMs on ML forum?

Main flash chip is MX29GL256FHXGI. Is it emulated properly in QEMU?
« Last Edit: 17 / July / 2016, 08:17:47 by Ant »
Logged
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: EOS M3 porting
« Reply #94 on: 17 / July / 2016, 08:42:29 »
FC003180 void uart_puts(char* msg) appears safe to call and doesn't seem to use any global state (so it doesn't require initialization).
Logged
*

Offline srsa_4c

  • ******
  • 4447
Re: EOS M3 porting
« Reply #95 on: 17 / July / 2016, 09:01:21 »
FWIW, if you manage to switch the camera to factory mode, you might be able to start the main firmware and do tricks from a diskboot.bin.
Factory mode leaves out much of the hw initialization, has no display and doesn't start PTP - camera looks nearly bricked.
However, UART and diskboot are available.
Factory mode is controlled by a flag in flash ROM. See event procedures that have "FactoryMode" in their name (addresses in funcs_by_name.csv, provided by finsig).
Logged
*

Offline Ant

  • *****
  • 508
Re: EOS M3 porting
« Reply #96 on: 17 / July / 2016, 09:47:19 »
Quote from: a1ex on 17 / July / 2016, 08:42:29
FC003180 void uart_puts(char* msg)

It works. Is it safe to call bootloader's fileIO functions?
Logged
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: EOS M3 porting
« Reply #97 on: 17 / July / 2016, 10:31:57 »
On the EOS codebase, bootloader file I/O functions can be called before you jump to main firmware, and main firmware file I/O can be called after the card is mounted (pretty late in the boot process). They can't be mixed - it locks up.

I'm not sure how it's done on CHDK - I see DISKBOOT.BIN referenced in two places: FC0005CC (Rescue Loader) and FC0637B2 (StartDiskboot, main firmware).

If you are running the debug shell, I guess DISKBOOT.BIN was loaded with the first method; in this case, you can probably call these functions:
Code: [Select]
FC0008A4 int mount_sd_card(void)
FC00257C int sd_load_file(int drive_maybe, char* filename, void* buffer, int unknown, int* out_file_size) // high-level function, e.g. sd_load_file(0, "DISKBOOT.BIN", 0x40008000, 0x5FC00000, &diskboot_size);
FC0008F4 sd_read_sector(int drive_maybe, int start_sector, int num_sectors, void* buffer) // low-level sector read function (512 bytes at a time)

If not, I guess DISKBOOT.BIN is loaded with the second method, and here I'm afraid you need to wait for the file I/O backend to get initialized. Or you might be lucky called the bootloader functions, not sure.

BTW, the latest QEMU is able to emulate file I/O on 80D bootloader, both read and write (also digic 6), so implementing this on M3 should be doable. Then we can find the answer to your question :)
Logged
*

Offline Ant

  • *****
  • 508
Re: EOS M3 porting
« Reply #98 on: 17 / July / 2016, 11:10:18 »
Text messages "NotInit", "StartDiskboot", "Start Program on RAM" are printed from main firmware.
Logged
*

Online reyalp

  • ******
  • 13675
Re: EOS M3 porting
« Reply #99 on: 17 / July / 2016, 15:22:13 »
Yikes  :(
Quote from: srsa_4c on 17 / July / 2016, 09:01:21
FWIW, if you manage to switch the camera to factory mode, you might be able to start the main firmware and do tricks from a diskboot.bin.
Factory mode leaves out much of the hw initialization, has no display and doesn't start PTP - camera looks nearly bricked.
However, UART and diskboot are available.
Factory mode is controlled by a flag in flash ROM. See event procedures that have "FactoryMode" in their name (addresses in funcs_by_name.csv, provided by finsig).
Old discussion of factory mode:
https://chdk.setepontos.com/index.php?topic=4417.20

The fact the bricking happened "after experimenting with language menu" makes me think of corrupt flash params: https://chdk.setepontos.com/index.php?topic=5660.10 but if all the adjustment data is wiped out, this won't help. There are a bunch of factory mode function related to adjustment table. It's possible there's a backup in ROM somewhere.

Note both of the above are quite old, function names in modern firmware are likely to have changed.

Quote from: Ant on 17 / July / 2016, 11:10:18
Text messages "NotInit", "StartDiskboot", "Start Program on RAM" are printed from main firmware.
Normally, CHDK diskboot is started by the main firmware, AFAIK the romstarter case is only used if the main firmware is missing (judged by the first word or so), or something to do with "UART loopback switch ON..."
Logged
Don't forget what the H stands for.
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 71   Go Up
« previous next »
 

Related Topics