EOS M100 porting

c_joerg

srsa_4c
I've never seen it blinking twice. Maybe it depends on card...?

Good hint. I have now tested two SD cards:
1) SanDisk Extreme PRO 32GB SD (Fast)
2) SanDisk Ultra 32GB Mirco SD with Adapter (Slow)

Blinking of booth cards is the same but

On the fast SD I have to wait only around 2s (after second LED).
With the slow SD card, I have to wait at least 10s after closing SD door.

srsa_4c
That's probably a lockup or crash (never seen that either). Do you get new romlog with matching timestamp after that (I suspect not)?

I got always a romlog with matching timestamp. I got different results on both cards.
Romlog attached.

ROMLOG_M100_PowerOn_SD_Fast.LOG

638b

ROMLOG_M100_PowerOn_SD_Slow.LOG

516b

srsa_4c

After (lots of) trials, I don't have anything conclusive.
It seems certain that the "classic" boot method (using copied asm code) has no such booting issues.
It does not seem to matter where in RAM I put the CHDK core, the copied ROM pages or the L2 translation tables. A certain combination either has one or more of the boot problems or has (seemingly) none.
In the attached update, I added some more cache cleaning operations, now executed on both cores. It seems to have no issue with card door boot or battery door boot - on my camera.

I feel that the camera's design is making this research harder, adding an additional point of uncertainty. The DIGIC's start in this camera is controlled by the subcpu (which handles some of the buttons and detects the door switches).

m100_100a_201012.7z

93.99KB

Ant

srsa_4c DIGIC's start in this camera is controlled by the subcpu (which handles some of the buttons and detects the door switches).

In EOS M3 the subcpu also handles lens detection when the camera is switched off.

c_joerg

srsa_4cIn the attached update, I added some more cache cleaning operations, now executed on both cores.

I compared the update with my sources and I only see differences in black level calculationâ€¦
Black Level at ISO100 is now 511.

But now I've discovered another problem. Sometimes setting the exposure time and ISO doesn't work in RAWOPINT. All images then have the same exposure time and ISO.

I once did three runs in a behind with changing some parameters. Setting Tv and ISO only worked in the second run. The camera was not switched off in the meantime.
Here is an example. The values read by the camera fluctuate slightly.

tv 821 != cam 840
tv 797 != cam 839
tv 769 != cam 839
tv 739 != cam 839
tv 708 != cam 839
tv 676 != cam 840
tv 644 != cam 839
tv 612 != cam 841
tv 580 != cam 838
tv 548 != cam 840

During the fourth run, the camera crashed for the first time. ROM log is attached.

rawopint.csv

15.25KB

ROMLOG_rawopint.LOG

11.97KB

Caefix

Booting Romlog.Lua... ???
At the moment both doorsÂ´ activity seems to prepare Romlog in background.
(The 'slow' card is my fastest...)
Same condition, not same Romlog? Some lines differ more or less.
(& there is always some 'noise' in the lens.)

BatROMLOG.txt

2.39KB

SDROMLOG.txt

1.33KB

srsa_4c

c_joerg
I compared the update with my sources and I only see differences in black level calculationâ€¦
Black Level at ISO100 is now 511.

But now I've discovered another problem. Sometimes setting the exposure time and ISO doesn't work in RAWOPINT. All images then have the same exposure time and ISO.

I once did three runs in a behind with changing some parameters. Setting Tv and ISO only worked in the second run. The camera was not switched off in the meantime.

Were you using a build made from the latest source? (it has more changes under platform/m100/sub/100a). In that source, I replaced the classic capt_seq_task code with minimal ROM hooks. If, for some reason, the MMU is switched to the ROM tables, those hooks will fail to work. But I don't see why it would switch to the ROM tables.

During the fourth run, the camera crashed for the first time. ROM log is attached.

It's due to an unexpected value (don't know what it's supposed to be), not a disaster-like exception that I see in the other romlogs. Anyway, it's not good.

Caefix
At the moment both doorsÂ´ activity seems to prepare Romlog in background.

Does this happen while using the latest source?

The short romlogs are all exceptions, CPU is wandering off executing garbage (for some reason, the exception addresses are all in uncached RAM).

If the latest source is that bad, downgrade to a stabler source until I have an idea what to do...

c_joerg

srsa_4c
Were you using a build made from the latest source? (it has more changes under platform/m100/sub/100a). In that source, I replaced the classic capt_seq_task code with minimal ROM hooks.

You are right. I missed the subdirectory by comparing with Beyond compare.
But I updated the whole zip by copying over the old version.

srsa_4c
If the latest source is that bad, downgrade to a stabler source until I have an idea what to do...

I can't say it's that bad. I've just looked at rawopint's older logs once again. I had the error even before the update.

Caefix

The door issue isnÂ´t very disturbing ( 🧑‍🎄 me ).
It could overwrite a crashlog in the worst case I see.
I enjoy a tool for a single key...

place2.Lua

4.62KB

c_joerg

srsa_4c
If the latest source is that bad, downgrade to a stabler source until I have an idea what to do...

I went back to the first version (m100_100a_201002_filesonly.7z.).
Here, too, there was already the problem with ISO and Tv at rawopint.
The only difference is that the problem with the SD card door didn't exist. But that is Ok for me.

With the last version, it looks like, I donâ€™t have problems with rawopint,
if the interval is not too short and I avoid the continuous mode.

srsa_4c

c_joerg
I went back to the first version (m100_100a_201002_filesonly.7z.).
Here, too, there was already the problem with ISO and Tv at rawopint.
The only difference is that the problem with the SD card door didn't exist. But that is Ok for me.

With the last version, it looks like, I donâ€™t have problems with rawopint,
if the interval is not too short and I avoid the continuous mode.

Thanks for the observations. It seems likely that the capt_seq hooks need better placement. I'll add debug output in the next release. But my main concern is the boot issues - I need to find out what I'm doing wrong when I do the memory remapping.

Caefix

??? 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?~~
😐: Have overseen that...

srsa_4c

Caefix
??? 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.

Caefix

😀 Now I have a verry comfortable Romlogging.

--[[
@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.

Romlog.lua

3.1KB

gui_tbox.c

17.21KB

philmoz

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.

srsa_4c

philmoz
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:

srsa_4c
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):

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

philmoz

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

srsa_4c

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

reyalp

srsa_4c
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

chdkptp -e"exec require'camtests'.runbatch{bench=true,shoot=true,filexfer=true,xfersizebugs=true}

Caefix

My first verbous Romlog on M100 :lol
Task name: PhySw 😛 < Exc Registers > pressing shoot to end script, cam died after (within?) focusbeep...

&& Once happened

*** 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 ***

srsa_4c 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/d/14123/2

[upl-file uuid=e7b55b6d-d58a-41b2-8b81-86f3f952aaa0 size=14.26KB url=https://chdk.setepontos.com/assets/files/2026-04-14/1776165180-408513--Romlog.txt]!Romlog.txt[/upl-file]

srsa_4c

Caefix
My first verbous Romlog on M100
Task name: PhySw
< Exc Registers > pressing shoot to end script, cam died after (within?) focusbeep...

&& Once happened[code]*** 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 ***[/code]

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.

« Previous Page Next Page »