EOS M100 porting - page 6 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 20   Go Down

EOS M100 porting

  • 199 Replies
  • 69767 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 »
Logged
All lifetime is a loan from eternity.
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #51 on: 13 / October / 2020, 17:12:14 »
Quote from: Caefix on 13 / October / 2020, 14:27:59
??? 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.
Logged
*

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.
Logged
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.

Logged
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 »
Quote from: philmoz 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.
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:
Quote from: srsa_4c on 10 / October / 2020, 18:20:30
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):
Quote from: srsa_4c on 01 / December / 2019, 13:21:54
- 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.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: EOS M100 porting
« Reply #55 on: 17 / October / 2020, 20:50:37 »
Quote from: srsa_4c on 17 / October / 2020, 19:42:54
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.

Logged
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 »
Quote from: philmoz on 17 / October / 2020, 20:50:37
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.
Logged
*

Offline reyalp

  • ******
  • 14118
Re: EOS M100 porting
« Reply #57 on: 18 / October / 2020, 14:22:09 »
Quote from: srsa_4c on 18 / October / 2020, 07:35:19
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}
Logged
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 ***
Quote from: srsa_4c on 13 / October / 2020, 17:12:14
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 »
Logged
All lifetime is a loan from eternity.
*

Offline srsa_4c

  • ******
  • 4451
Re: EOS M100 porting
« Reply #59 on: 19 / October / 2020, 17:28:12 »
Quote from: Caefix on 19 / October / 2020, 12:44:15
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.
Logged
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 20   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal