EOS M100 porting - page 6 - DryOS Development - CHDK Forum

EOS M100 porting

  • 199 Replies
  • 70716 Views
*

Offline Caefix

  • *****
  • 947
  • Sorry, busy deleting test shots...
Re: EOS M100 porting
« Reply #50 on: 13 / October / 2020, 14:27:59 »
Advertisements
 ??? You mean Boot to <play> after (short) ON on M100?
Are doors & booting somehow connected?
Theese Exceptions are not reporting a boot issue.
Edit2: Maybe You could add a first notes.txt to next release?
 :blink: Have overseen that...
« Last Edit: 13 / October / 2020, 16:11:20 by Caefix »
All lifetime is a loan from eternity.

*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #51 on: 13 / October / 2020, 17:12:14 »
??? You mean Boot to <play> after (short) ON on M100?
Are doors & booting somehow connected?
Theese Exceptions are not reporting a boot issue.
The issues (on my cam at least) always seem to happen when the boot reason is not camera start. The crash most likely happens when the DIGIC is first started due to a closed door or similar. Short blink of the LED means that the diskboot.bin was started.

*

Offline Caefix

  • *****
  • 947
  • Sorry, busy deleting test shots...
Re: EOS M100 porting
« Reply #52 on: 14 / October / 2020, 15:37:17 »
 :) Now I have a verry comfortable Romlogging.
Code: [Select]
--[[
@title save ROM crash log to ROMLOG.LOG
@chdk_version 1.3
requires CHDK built with native function call support
@param   a remove old files 1=yes, 0=no
@default a 1
@range   a 0 1
@param   b append buildinfo
@default b 1
@range   b 0 1
@param   n Take a look
@default n 1
@range   n 0 1
@param   R Rename Romlog.Log
@default R 0
@range   R 0 1
@param   M Merge to !Romlog.txt
@default M 1
@range   M 0 1
--]]
& found a line to much   (here 410:    break;)   in gui_tbox.c to get some space (now <set>) in M100 textbox().
( // backspace is <shoot_half> in 'Move' )
Same on other cams, has not disturbed yet.
All lifetime is a loan from eternity.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: EOS M100 porting
« Reply #53 on: 17 / October / 2020, 18:59:01 »
I have weird behaviour on the G7X2 when uploading / deleting DNG files from the DCIM image folder.


I'm curious if the same happens on the M100, if anyone has time to test it.


Uploading (with chdkptp) or deleting a .DNG file from the JPEG image folder crashes the camera if it is plugged into the PC via USB.
Crash is in FsIoNotify task, ObjTreeMgr.c module, line 804.


The file does not have to be a real DNG file or an image taken with the camera, so long as the name is in the normal image format (IMG_xxxx.DNG) then it will crash when uploaded or deleted. Deleting can be with the CHDK file browser or via chdkptp.


It also crashes if the file extension is .CRW.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #54 on: 17 / October / 2020, 19:42:54 »
I have weird behaviour on the G7X2 when uploading / deleting DNG files from the DCIM image folder.


I'm curious if the same happens on the M100, if anyone has time to test it.


Uploading (with chdkptp) or deleting a .DNG file from the JPEG image folder crashes the camera if it is plugged into the PC via USB.
Crash is in FsIoNotify task, ObjTreeMgr.c module, line 804.


The file does not have to be a real DNG file or an image taken with the camera, so long as the name is in the normal image format (IMG_xxxx.DNG) then it will crash when uploaded or deleted. Deleting can be with the CHDK file browser or via chdkptp.


It also crashes if the file extension is .CRW.
I tried a few combinations with dummy files (CRW, DNG) matching the name of a real JPG. No crashes.

FWIW, there is one issue that may affect operations that involve CPU cache:
It also occurred to me that the CPU cache routines used in CHDK may not be adequate in a dual-core setup. We're probably only clearing the cache on one core...
I suspect (but did not verify) that the cache controller might be L2C310, as mentioned in the Cortex A9 ARM docs. We could either use firmware routines, replacing the lib/armutil/cache.c routines with equivalents, or make our own versions. But I have not looked up the necessary routines yet.

Now, I don't know whether caching is involved in this case, but it might be worth a look. Otherwise, you might be having some unknown corruption issue like I did (or still do):
- There is an ugly memory corruption issue which I can't currently reproduce. It appeared to be triggered by saving a romlog from menu, crash happened on the next GetMemInfo call. At least one fw variable (used by GetMemInfo) was corrupted.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: EOS M100 porting
« Reply #55 on: 17 / October / 2020, 20:50:37 »
I tried a few combinations with dummy files (CRW, DNG) matching the name of a real JPG. No crashes.


Thanks for testing.


I don't think it's cache related.
If I rename the file in our 'remove' function before deleting it, then the camera does not crash.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #56 on: 18 / October / 2020, 07:35:19 »
I don't think it's cache related.
If I rename the file in our 'remove' function before deleting it, then the camera does not crash.
Curious, I looked at the assert line numbers in ObjTreeMgr.c routines - they match in g7x2 and m100. So, the version of this library is likely the same in both cameras.

About caching:
I don't think we'll get away without having caching problems. The physw task is started on core1, task_startup runs on core0, spytask is started by task_startup via regular CreateTask, which (if this observation is true) means it's on core0 too. When we load a module, icache and dcache is cleared/cleaned on the core that performs the load, but caches (probably L2) are not currently sync'd.

*

Offline reyalp

  • ******
  • 14121
Re: EOS M100 porting
« Reply #57 on: 18 / October / 2020, 14:22:09 »
About caching:
I don't think we'll get away without having caching problems. The physw task is started on core1, task_startup runs on core0, spytask is started by task_startup via regular CreateTask, which (if this observation is true) means it's on core0 too. When we load a module, icache and dcache is cleared/cleaned on the core that performs the load, but caches (probably L2) are not currently sync'd.
IIRC, it took quite some time for the cache problems to be apparent in the module code, so it wouldn't be surprising if it seemed to "work" and then failed in confusing ways. But I'd be pretty surprised if this was what philmoz is seeing.

That said, CHDK does a lot of things that are bad and scary in a multi-core environment, for example, all the things that wait in a loop on a variable set in another task.
 
PTP might be another place one would expect problems, since there are handoffs through shared memory structures between the PTP task and physw. Running the full camtests suite should be a decent stress test
Code: [Select]
chdkptp -e"exec require'camtests'.runbatch{bench=true,shoot=true,filexfer=true,xfersizebugs=true}
Don't forget what the H stands for.


*

Offline Caefix

  • *****
  • 947
  • Sorry, busy deleting test shots...
Re: EOS M100 porting
« Reply #58 on: 19 / October / 2020, 12:44:15 »
My first verbous Romlog on M100  :lol
Task name: PhySw  :o
< Exc Registers > pressing shoot to end script, cam died after (within?) focusbeep...

&& Once happened
Code: [Select]
*** GESTARTET ***
rm A/ROMLOG.LOG: true
A/ROMLOG.LOG exists
Occured Time  2020:10:14
17:59:50
A/CHDK/SCRIPTS/EDITOR/Rom
log.lua:808464944: 'for'
initial value must be a n
umber
*** ABGEBROCHEN ***

Short blink of the LED means that the diskboot.bin was started.
...but no delay after lens attachment.

++ External lens to dof. snippet. (get_zoom() ++)
https://chdk.setepontos.com/index.php?topic=14123.msg144340#msg144340
« Last Edit: 19 / October / 2020, 15:05:43 by Caefix »
All lifetime is a loan from eternity.

*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #59 on: 19 / October / 2020, 17:28:12 »
My first verbous Romlog on M100
Task name: PhySw
< Exc Registers > pressing shoot to end script, cam died after (within?) focusbeep...

&& Once happened
Code: [Select]
*** GESTARTET ***
rm A/ROMLOG.LOG: true
A/ROMLOG.LOG exists
Occured Time  2020:10:14
17:59:50
A/CHDK/SCRIPTS/EDITOR/Rom
log.lua:808464944: 'for'
initial value must be a n
umber
*** ABGEBROCHEN ***

These could be memory corruption related (caching issue or not). One or more your romlogs are startup crashes (mentioned earlier).

Once I find time to continue working on this, I'll surely add zoom/focal length support, after finding the right caching functions and reviewing capt_seq code.

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal