Magic Lantern Forum
Developing Magic Lantern => General Development => Topic started by: srsa on September 03, 2020, 01:11:27 AM
-
I'm moving this to a separate thread as it turned out that more models have support for scripting.
So far confirmed to exist on:
PowerShot SX740
EOS M50
EOS R, RP, R5, R6
EOS 250D
About the language (https://chdk.fandom.com/wiki/Canon_Basic). Card setup (https://chdk.fandom.com/wiki/Canon_Basic/Card_Setup).
Note that some people have problems making a usable script card. If that happens, try again. If in doubt, a card prepared for scripting can be verified on any older PowerShot from ~2005 on. The card probably needs to be formatted FAT16/32.
Any script error will crash the camera and require a battery pull.
The language used on DIGIC 8 models is the same as described on the above links, but CHDK-related scripts will not work. The reason for this is that the so-called event procedures (https://chdk.fandom.com/wiki/Event_Procedure) (named firmware functions) are mostly different.
Unlike on older PowerShots, most of the available event procedures are pre-registered - can be used without running registration procedures.
Also unlike on older cameras, it is possible to try executing an eventproc that may not exist. This can be achieved by using ExecuteEventProcedure.
ExecuteEventProcedure("Peek32",0x1000)is equivalent to
Peek32(0x1000)and will return the word read from address 0x1000
ExecuteEventProcedure("arbitrary_invalid_function")will return -1
Native code can be executed by using ExportToEventProcedure
ExportToEventProcedure("my_func",0xe1234567)will make the firmware function at 0xe1234566 (with thumb bit) available for script as eventproc my_func
All variables of the script are 32-bit signed integers, interpreted as integer, pointer, pointer to string, as required.
It's worth to note that operator precedence is different from other languages. Negative numbers (that includes pointers to ROM) can have funny effects in expressions involving more than two numbers.
File handling capabilities are quite limited when using only available event procedures - native code must be found and used for reading anything from file, writing a binary file, erasing a file, etc.
String constants are limited to 127 bytes. sprintf() only allows up to 8 substitutions (probably a language limit).
The available event procedures can be harvested from ROM, by looking up the registration functions in the disassembly.
Some example scripts
ROM dumper (main image from 0xe0040000, without bootloader)
private sub Initialize()
SaveBootableToFile()
end sub
ROM dumper, not working on M50 due to missing eventproc
private sub Initialize()
SaveAllRomImageToFile()
end sub
Enable bootflag
private sub Initialize()
EnableBootDisk()
end sub
Disable bootflag
private sub Initialize()
DisableBootDisk()
end sub
Dumping camera log (current session)
private sub Initialize()
dumpf()
end sub
I posted a slow dumper script in this older post (https://www.magiclantern.fm/forum/index.php?topic=23296.msg227190#msg227190).
Finally, the usual warning: do not post your ROM dumps publicly.
-
Very cool, thanks for sharing the low-level details!
Also confirmed to work on EOS RP.
-
So all eyes are now on R5/R6? 8)
Thank you srsa! I'm still amazed how we overlooked your original post for a few months.
-
Is there any chance someone could create a known-working 256MB SD card image that contains a sample (ROM dumper or otherwise) script, compress it and get that added to the first post? I for one would like to try it with the R5, to eliminate any possibility I messed up when trying to create my own scriptable card.
I'd also like to try this on a CFExpress card to eliminate any drive letter issues. I have one on order but unfortunately it might not arrive in time for my departure on a long trip next week. If it does get here before then I'll test and report back. The SD card slot shows up as "Card 2" in the Canon menus, if that helps (the 5D Mark IV also shows its SD slot as "Card 2").
-
How do you test Canon basic scripts?
Is there a syntax check or debug facility?
Or do you have to take out the card every time and try again?
-
I recommend removing battery ...
-
When I got ERR70 due to calling wrong (not existing?) function on R, it was enough to open card door. Error disappeared from top screen, camera booted as usual.
-
Is there any chance someone could create a known-working 256MB SD card image that contains a sample (ROM dumper or otherwise) script, compress it and get that added to the first post? I for one would like to try it with the R5, to eliminate any possibility I messed up when trying to create my own scriptable card.
I second this statement. It is super unlikely that we both messed up, but this would be to make sure that we didn't mess up.
Can someone please create that working SD card image so that we can try it on the R5 and R6?
-
I'll do it. Expect dd image around 5PM CEST.
-
Card image (https://kitor.pl/eos_r/card.img.gz)
Image of 512MB card. Uncompress, and use DD or Win32DiskImager to write to any card of the same size, or above.
Has rom dumper script. Worked fine on R.
After you put card in your camera, go to play mode and press ???. In case of R it was Q/Set, but those are separate buttons now. Set is better candidate as it's Func./Set on powershots :)
If access led will go red, or camera will crash - we are golden.
-
Thanks kitor, much appreciated. I tried various combinations of Play followed by buttons and dials, pulling the battery each time (not sure that's needed or not?) using your image. I also tried it with and without an image on the card in case that matters, and with the card write protected. Unfortunately still no luck on the R5, so either the way to trigger it isn't very obvious or scripting doesn't work at all :(
-
Maybe subject needs to be chanced a bit. My 250D/200D Mark II/Rebel SL3/Kiss X10 does execute Canon Basic script and produces ROM.TXT.
Zero Bytes but it is written nevertheless!
Correction: 2 129 920 Bytes
Want to have a look? -> PN
Any hints what is needed to dump valid bits and bytes?
90D, M6 II, G7X III: Users around? Making a script card is easy!
If there are troubles I promise to assist via Teamviewer (or else).
-
Maybe subject needs to be chanced a bit. My 250D/200D Mark II/Rebel SL3/Kiss X10 does execute Canon Basic script and produces ROM.TXT.
Hmmm, what an avalanche. Changed the 1st post and thread title.
If you want something more useful and faster, try
private sub Initialize()
r = ExecuteEventProcedure("SaveAllRomImageToFile")
if r = -1 then
ExecuteEventProcedure("SaveBootableToFile")
end if
end subI gladly accept (links to) dumps in PM.
-
Thanks! Cam is 250D, not 200D. ;-)
-
Thanks! Cam is 250D, not 200D. ;-)
Corrected.
-
I also tried it with and without an image on the card in case that matters, and with the card write protected
Have you tried both card slots? It was mentioned a couple of times that this needs to be B:\ from DryOS PoV, and we don't know the actual mapping.
-
Have you tried both card slots?
I tried the Kitor card.img on both slots on the R6. Nothing
-
Card verified to work in other cam?
If not: Card size? Partition size? File system?
-
Yes. Kitor sent us his card image that has been verified. If you have another working card image I'll be happy to try that
-
No, there is no verification this card is working. It is verified Kitor's card is working not the one in your hand.
Use a Digic 8 camera or almost any PowerShot codebased cam produced after 2005.
-
Just FYI - in both cases (512MB SD and 32GB via adapter) it was Sandisk cards.
-
I tried the Kitor card.img on both slots on the R6. Nothing
What is the size of the card you tried?
-
The card I tried is 128GB originally. I don't have any other card size. I'll go out and try to buy a cheap sd card that's smaller.
I also don't have any other camera. ( I do know someone with an M50 though. Maybe I can try to borrow that one but I won't be able to do that until sunday or monday.)
-
You can create a partition <32 GB.
See Kitor's post https://www.magiclantern.fm/forum/index.php?topic=25305.msg230427#msg230427
-
There need to try SD or SDHC(not SDXC) card first. Is that so hard?
-
WORKS ON R6!!!!
https://www.magiclantern.fm/forum/index.php?topic=24827.msg230456#msg230456
Might want to change the subject of this thread to DIGIC 10 too.
-
Canon Basic script for running a small binary. The five function addresses listed at start are required to be correct. The initial values are for sx740 1.0.1
The binary is loaded in uncached RAM and executed as-is. The firmware always applies cache and branch predictor related routines on code loaded to RAM, so there is a possibility that this approach is not fully reliable.' firmware function addresses with thumb bit
dim a_fio_readf=0xE0520E8B ' FIO_ReadFile
dim a_fio_writef=0xE0521027 ' FIO_WriteFile
dim a_fio_removf=0xE0520DF1 ' FIO_RemoveFile (newer cams have an equivalent RemoveFile eventproc)
dim a_umalloc=0xE053A0B1 ' AllocateUncacheableMemory
dim a_ufree=0xE053A0E5 ' used to free AllocateUncacheableMemory allocations (not named)
dim cpuinf_binary="B:/CPUINFO.BIN"
dim cpuinf_data="B:/CPUINFO.DAT"
private sub reg_funcs1()
ExportToEventProcedure("FIO_ReadFile",a_fio_readf|1)
ExportToEventProcedure("FIO_WriteFile",a_fio_writef|1)
ExportToEventProcedure("FIO_RemoveFile",a_fio_removf|1)
ExportToEventProcedure("umalloc",a_umalloc|1)
ExportToEventProcedure("ufree",a_ufree|1)
end sub
private sub Initialize()
reg_funcs1()
buf = umalloc(0x1000)
if buf=0 then
exit sub
end if
bufo = umalloc(0x1000)
if bufo=0 then
ufree(buf)
exit sub
end if
memset(bufo,0,0x1000)
f = OpenFileRD(cpuinf_binary)
FIO_ReadFile(f,buf,0x1000)
CloseFile(f)
ExportToEventProcedure("cpuinfo",buf|1)
cpuinfo(bufo)
FIO_RemoveFile(cpuinf_data)
f = OpenFileCREAT(cpuinf_data)
CloseFile(f)
f = OpenFileWR(cpuinf_data)
FIO_WriteFile(f,bufo,0x1000)
CloseFile(f)
ufree(bufo)
ufree(buf)
end sub
Assembly source for the current CPUINFO code from here (https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/modules/cpuinfo_v7.c). It now supports ARMv7 VMSA (such as Cortex A9) CPUs.
@ compile with:
@ arm-none-eabi-gcc -Wl,-N,-Ttext,0x800000 -nostdlib -march=armv7 -mthumb cpuinfo.s -o cpuinfo.elf
@ and extract the needed bytes from the binary:
@ arm-none-eabi-objcopy -O binary cpuinfo.elf cpuinfo.bin
@ toolchain: [url]https://launchpad.net/gcc-arm-embedded[/url]
@ 0x00800000 is an arbitrary address, code is position independent anyway
.macro NHSTUB name addr
.globl _\name
.weak _\name
_\name:
ldr.w pc, _\addr
_\addr:
.long \addr
.endm
.globl _start
.org 0
_start:
.text
@ force thumb
.code 16
@ allow new instructions (ldr.w)
.syntax unified
MRC p15, 0, R1,c0,c0 @ ident
STR R1, [R0]
MRC p15, 0, R1,c0,c0,1 @ CTR, cache
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c0,2 @ TCMTR, TCM
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c0,3 @ TLBTR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c2,c0,2 @ TTBCR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c2,c0,0 @ TTBR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c2,c0,1 @ TTBR1
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c0,5 @ MPIDR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c0,6 @ REVIDR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,0 @ ID_PFR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,1 @ ID_PFR1
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,2 @ ID_DFR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,3 @ ID_AFR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,4 @ ID_MMFR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,5 @ ID_MMFR1
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,6 @ ID_MMFR2
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c1,7 @ ID_MMFR3
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,0 @ ID_ISAR0
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,1 @ ID_ISAR1
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,2 @ ID_ISAR2
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,3 @ ID_ISAR3
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,4 @ ID_ISAR4
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c0,c2,5 @ ID_ISAR5
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 1, R1,c0,c0,1 @ CLIDR
ADD R0, R0, #4
STR R1, [R0]
MOV R1, #0
MCR p15, 2, R1,c0,c0,0 @ CSSELR (data cache, level0)
MRC p15, 1, R1,c0,c0,0 @ CCSIDR (the currently selected one)
ADD R0, R0, #4
STR R1, [R0]
MOV R1, #1
MCR p15, 2, R1,c0,c0,0 @ CSSELR (inst cache, level0)
MRC p15, 1, R1,c0,c0,0 @ CCSIDR (the currently selected one)
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c1,c0,0 @ SCTLR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c1,c0,1 @ ACTLR
ADD R0, R0, #4
STR R1, [R0]
@#ifndef CONFIG_QEMU
MRC p15, 0, R1,c15,c0,0 @ ACTLR2
ADD R0, R0, #4
STR R1, [R0]
@#endif
MRC p15, 0, R1,c1,c0,2 @ CPACR
ADD R0, R0, #4
STR R1, [R0]
@"MRC p15, 0, R1,c9,c1,1 @ ATCM region reg, Cortex R4
@"ADD R0, R0, #4
@"STR R1, [R0]
@"MRC p15, 0, R1,c9,c1,0 @ BTCM region reg, Cortex R4
@"ADD R0, R0, #4
@"STR R1, [R0]
MRC p15, 0, R1,c1,c1,2 @ NSACR
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c3,c0,0 @ DACR
ADD R0, R0, #4
STR R1, [R0]
MRC p14, 0, R1,c0,c0,0 @ DBGDIDR
ADD R0, R0, #4
STR R1, [R0]
MRC p14, 0, R1,c1,c0,0 @ DBGDRAR
ADD R0, R0, #4
STR R1, [R0]
MRC p14, 0, R1,c2,c0,0 @ DBGDSAR
ADD R0, R0, #4
STR R1, [R0]
MRC p14, 0, R1,c0,c1,0 @ DBGDSCR
ADD R0, R0, #4
STR R1, [R0]
@".word 0xEEF01A10 @"VMRS R1, FPSID @ Floating Point System ID register
@"ADD R0, R0, #4
@"STR R1, [R0]
@".word 0xEEF71A10 @"VMRS R1, MVFR0 @ Media and VFP Feature Register 0
@"ADD R0, R0, #4
@"STR R1, [R0]
@".word 0xEEF61A10 @"VMRS R1, MVFR1 @ Media and VFP Feature Register 1
@"ADD R0, R0, #4
@"STR R1, [R0]
MRC p15, 4, R1,c15,c0,0 @ config base addr reg (Cortex A9)
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c11,c0,0 @ PLEIDR (Cortex A9)
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c10,c0,0 @ TLB lockdown reg (Cortex A9)
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c10,c2,0 @ PRRR (Cortex A9)
ADD R0, R0, #4
STR R1, [R0]
MRC p15, 0, R1,c10,c2,1 @ NMRR (Cortex A9)
ADD R0, R0, #4
STR R1, [R0]
BX LR
I already executed this on my camera and found no big differences from DIGIC 7.
Running this on R5 or R6 would be more interesting.
Evaluating the CPUINFO.DAT binary is currently only possible on a D6-D7 CHDK cam with patched CPUINFO module. Porting the evaluator to "PC" would solve that.
Index: modules/cpuinfo.c
===================================================================
--- modules/cpuinfo.c (revision 5564)
+++ modules/cpuinfo.c (working copy)
@@ -66,17 +66,36 @@
char buf[100];
char *p;
#ifdef THUMB_FW
+ int pmsa = 0;
struct cpuinfo_word_desc_s *cpuinfo_desc;
- if (cpu_is_vmsa()) {
- FILE *f=fopen("A/MMU_MAP.CSV", "wb");
- memmapping_vmsa(f);
- cpuinfo_get_info_vmsa(cpuinfo);
+
+ finfo = fopen("A/CPUI_V7V.DAT","rb");
+ if (!finfo) {
+ finfo = fopen("A/CPUI_V7P.DAT","rb");
+ pmsa = 1;
+ }
+ if (!finfo) {
+ pmsa = !cpu_is_vmsa();
+ if (cpu_is_vmsa()) {
+ FILE *f=fopen("A/MMU_MAP.CSV", "wb");
+ memmapping_vmsa(f);
+ cpuinfo_get_info_vmsa(cpuinfo);
+ }
+ else {
+ cpuinfo_get_info_pmsa(cpuinfo);
+ }
+ }
+ else {
+ fread(cpuinfo, 4, NUM_CPUINFO_WORDS, finfo);
+ fclose(finfo);
+ }
+ if (!pmsa) {
cpuinfo_desc = (struct cpuinfo_word_desc_s*) cpuinfo_desc_vmsa;
}
else {
- cpuinfo_get_info_pmsa(cpuinfo);
cpuinfo_desc = (struct cpuinfo_word_desc_s*) cpuinfo_desc_pmsa;
}
+
#else
cpuinfo_get_info(cpuinfo);
#endif
-
Thanks, this is quite interesting. Are you aware of Scout debugger?
https://github.com/CheckPointSW/Scout
In theory this can be loaded into Canon cams and act as a network debugger. I played with it briefly but couldn't work out how to build it.
-
Thanks, this is quite interesting. Are you aware of Scout debugger?
https://github.com/CheckPointSW/Scout
It was mentioned in their ransomware article. Never tried to use it.
In theory this can be loaded into Canon cams and act as a network debugger.
They mention it worked, but the subject was a DIGIC 6 camera. DIGIC 7 and later has a separate core for networking. The firmware refers to it as "Lime". That CPU is not ARM, it's Xtensa. And that architecture is not supported by Scout.
-
Maybe subject needs to be chanced a bit. My 250D/200D Mark II/Rebel SL3/Kiss X10 does execute Canon Basic script and produces ROM.TXT. Zero Bytes but it is written nevertheless!
Correction: 2 129 920 Bytes
Want to have a look? -> PN
Any hints what is needed to dump valid bits and bytes?
90D, M6 II, G7X III: Users around? Making a script card is easy!
If there are troubles I promise to assist via Teamviewer (or else).
hi i have, m6 mkii 1.1.0 , i need ML)))
-
hi i have, m6 mkii 1.1.0 , i need ML)))
Fine! Start coding and repost with an early beta. Est. 2023.
-
I found stubs for R6, got cpuinfo dumper built. Thanks to @yourboylloyd who is a brave tester, we can confirm it works. I'm now porting the code to linux so I can view the results.
-
superb! thanx for keeping us updated.
-
I found stubs for RP and dumped cpuinfo on my cam. I will publish the results once the parser of names_are_hard is ported.
RP stubs for firmware 1.5.0 are:
dim a_fio_readf=0xE0584C07 ' FIO_ReadFile
dim a_fio_writef=0xE0584D9F ' FIO_WriteFile
dim a_fio_removf=0xE0584B6F ' FIO_RemoveFile (newer cams have an equivalent RemoveFile eventproc)
dim a_umalloc=0xE0594A8D ' AllocateUncacheableMemory
dim a_ufree=0xE0594AC1 ' used to free AllocateUncacheableMemory allocations (not named)
-
I have a crude early port of the cpuinfo parser. There's some conditional stuff around VMSA, PMSA and v5 / v7 that for now I ignore. I don't have a good way to check if the output is sensible. Here's a truncated example:
./build/parser cpuinfo.rp.dat && cat CPUINFO.TXT
ID 0x414FC091
Revision 0x1 1
Part 0xC09 3081
ARM Arch 0xF 15
Variant 0x4 4
Implementor 0x41 65
Cache type 0x83338003
Icache min words/line 0x3 3 [8]
(zero) 0x0 0
L1 Icache policy 0x2 2
Dcache min words/line 0x3 3 [8]
Exclusives Reservation Granule 0x3 3 [8]
Cache Writeback Granule 0x3 3 [8]
(zero) 0x0 0
(register format) 0x4 4
TCM type 0x00000000
(raw value) 0x0 0
TLB type 0x00000404
TLB 0x0 0 [Unified TLB]
TLB entries 0x2 2 [256]
- 0x0 0
Lockable unified or data entries 0x4 4
Lockable instruction entries 0x0 0
(zero) 0x0 0
Does that look obviously wrong to anybody?
@srsa - can I ignore memmapping_vmsa(), or is it important to get that working?
-
I don't have a good way to check if the output is sensible.
The output is correct. The parsed text can be added to this thread (https://www.magiclantern.fm/forum/index.php?topic=17714.0).
@srsa - can I ignore memmapping_vmsa(), or is it important to get that working?
That is only usable on camera, and only makes sense if one is trying to make changes to the memory translation.
I ended up hacking standalone support into the cpuinfo source (cpuinfo.c and cpuinfo_v7.c from here (https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/modules)). Patch below. The patched 2 files can be compiled with
gcc -m32 -o cpuinfo.exe -DCPUINFO_STANDALONE cpuinfo.c32-bit only due to arch-dependent types in source.
Index: modules/cpuinfo.c
===================================================================
--- modules/cpuinfo.c (revision 5570)
+++ modules/cpuinfo.c (working copy)
@@ -1,3 +1,5 @@
+#ifndef CPUINFO_STANDALONE
+
#include "stdlib.h"
#include "gui_mbox.h"
#include "gui.h"
@@ -4,6 +6,24 @@
#include "gui_lang.h"
#include "lang.h"
+#else // CPUINFO_STANDALONE
+
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+
+#define THUMB_FW 1
+
+const char *fni;
+const char *fno;
+static int is_vmsa = 1;
+
+int cpu_is_vmsa() {
+ return is_vmsa;
+}
+
+#endif // CPUINFO_STANDALONE
+
struct cpuinfo_bitfield_desc_s {
unsigned bits;
const char *name;
@@ -67,6 +87,7 @@
char *p;
#ifdef THUMB_FW
struct cpuinfo_word_desc_s *cpuinfo_desc;
+#ifndef CPUINFO_STANDALONE
if (cpu_is_vmsa()) {
FILE *f=fopen("A/MMU_MAP.CSV", "wb");
memmapping_vmsa(f);
@@ -77,10 +98,36 @@
cpuinfo_get_info_pmsa(cpuinfo);
cpuinfo_desc = (struct cpuinfo_word_desc_s*) cpuinfo_desc_pmsa;
}
+#endif // CPUINFO_STANDALONE
+
+#else // THUMB_FW
+ cpuinfo_get_info(cpuinfo);
+#endif // THUMB_FW
+
+#ifndef CPUINFO_STANDALONE
+ finfo=fopen("A/CPUINFO.TXT", "wb");
#else
- cpuinfo_get_info(cpuinfo);
+ finfo = fopen(fni,"rb");
+ if (!finfo) {
+ fprintf(stderr, "Failed to open input file\n\n");
+ return;
+ }
+ else {
+ fread(cpuinfo, 4, NUM_CPUINFO_WORDS, finfo);
+ fclose(finfo);
+ }
+ if (cpu_is_vmsa()) {
+ cpuinfo_desc = (struct cpuinfo_word_desc_s*) cpuinfo_desc_vmsa;
+ }
+ else {
+ cpuinfo_desc = (struct cpuinfo_word_desc_s*) cpuinfo_desc_pmsa;
+ }
+ finfo=fopen(fno, "wb");
+ if (!finfo) {
+ fprintf(stderr, "Failed to open output file\n\n");
+ return;
+ }
#endif
- finfo=fopen("A/CPUINFO.TXT", "wb");
for(i = 0; cpuinfo_desc[i].name; i++) {
wordval = cpuinfo[i];
sprintf(buf,"%-10s 0x%08X\n",cpuinfo_desc[i].name,wordval);
@@ -88,7 +135,7 @@
for(j=0; cpuinfo_desc[i].fields[j].name; j++) {
p=buf;
bits = cpuinfo_desc[i].fields[j].bits;
- mask = ~(0xFFFFFFFF << bits);
+ mask = (bits==32) ? 0xffffffff : ~(0xFFFFFFFF << bits);
fieldval = wordval & mask;
p+=sprintf(p," %-20s 0x%X %d",cpuinfo_desc[i].fields[j].name,fieldval,fieldval);
if(cpuinfo_desc[i].fields[j].desc_fn) {
@@ -100,10 +147,14 @@
}
}
fclose(finfo);
+#ifndef CPUINFO_STANDALONE
sprintf(buf, lang_str(LANG_CPUINFO_WROTE), "A/CPUINFO.TXT");
gui_mbox_init(LANG_MENU_DEBUG_CPU_INFO,(int)buf,MBOX_FUNC_RESTORE|MBOX_TEXT_CENTER, cpuinfo_finish);
+#endif // CPUINFO_STANDALONE
}
+#ifndef CPUINFO_STANDALONE
+
int basic_module_init() {
cpuinfo_write_file();
return 1;
@@ -136,3 +187,25 @@
/*************** END OF AUXILARY PART *******************/
+#else // CPUINFO_STANDALONE
+
+char *usage = "\nUsage: %s <cpuinfo.dat> <output file> [-p]\n\n";
+
+
+int main(int ac, const char **av) {
+
+ if (ac < 3) {
+ fprintf(stderr, usage, av[0]);
+ exit(0);
+ }
+ else if (ac > 3) {
+ if (strcmp(av[3], "-p") == 0) {
+ is_vmsa = 0;
+ }
+ }
+ fni = av[1];
+ fno = av[2];
+ cpuinfo_write_file();
+}
+
+#endif // CPUINFO_STANDALONE
Index: modules/cpuinfo_v7.c
===================================================================
--- modules/cpuinfo_v7.c (revision 5570)
+++ modules/cpuinfo_v7.c (working copy)
@@ -535,6 +535,7 @@
{}
};
+#ifndef CPUINFO_STANDALONE
void __attribute__((naked,noinline)) cpuinfo_get_info_pmsa(unsigned *results) {
asm (
@@ -809,6 +810,8 @@
);
}
+#endif // CPUINFO_STANDALONE
+
static const char * tlb_unified(unsigned val) {
switch(val) {
case 0: return "Unified TLB";
@@ -1007,6 +1010,8 @@
{}
};
+#ifndef CPUINFO_STANDALONE
+
void __attribute__((naked,noinline)) cpuinfo_get_info_vmsa(unsigned *results) {
asm (
".syntax unified\n"
@@ -1512,4 +1517,6 @@
fclose(f);
}
+#endif // CPUINFO_STANDALONE
+
-
Great! Added R6 and RP to thread.
I stole your bit twiddling fix and made a repo with my standalone tool. Tested on Linux, should be portable with minimal changes if anyone needs it.
https://github.com/reticulatedpines/cpuinfo_linux
Yours and mine produce identical output for R6 and RP.
-
So people are already working on the R6 with ML and skipping the M50 altogether?
-
A lot of work has been done on the M50, but there are no active developers working on the camera. If you have coding experience please help on the m50's development.
-
A lot of work has been done on the M50, but there are no active developers working on the camera. If you have coding experience please help on the m50's development.
I'd personally like to help, but I don't know where to start, as I don't know all that much about the way the firmware works. Could I ask if there are any relatively low-hanging fruit regarding the M50 that I could try and pick at?
-
I'd personally like to help, but I don't know where to start, as I don't know all that much about the way the firmware works. Could I ask if there are any relatively low-hanging fruit regarding the M50 that I could try and pick at?
First question: Are you willing to put several hundred hours of work into it?
-
First question: Are you willing to put several hundred hours of work into it?
I'm certainly more than willing to try. I'm aware of the amount of work necessary for this sort of thing, and unfortunately right now I don't really have much else to put hundreds of hours of work into…
I'm not about to give a resume here, both because I don't want to dox myself and because I don't feel like trying to convince anyone that I've got experience hacking hardware. But I can assure you I do, and I've been needing an excuse to learn ARM/thumb assembly anyway.
-
First question: Are you willing to put several hundred hours of work into it?
If so, feel free to join us on our unofficial discord server: https://discord.gg/uaY8akC
-
unfortunately right now I don't really have much else to put hundreds of hours of work into…
Sorry to read that!
Welcome on board and good luck (both ways!)
-
srsa posted some specific code here that can be used to get some interesting information out of the camera.
https://chdk.setepontos.com/index.php?topic=13943.msg144153#msg144153
private sub Initialize()
System.Create()
CamInfo_Debug(1)
end sub
The Canon Basic Code creates a CameraInfo.xml file.
The file contains information such as TotalShoot, TotalRunningTime, ErrorList ...
I would be interested in a CameraInfo.xml from an R5 and R6, especially one that has already crashed.
A CameraInfo.xml of my M100 is here (renamed to txt).
https://chdk.setepontos.com/index.php?topic=13943.msg144154#msg144154
-
I would be interested in a CameraInfo.xml from an R5 and R6, especially one that has already crashed.
Here's the CameraInfo.xml from my R5 (serial number removed):
<?xml version="1.0"?><Canon><CameraInfo><Serial>xxxxxxxxxxxx</Serial><FirmwareVer><Internal>0.4.0.5</Internal><Major>1.1.0</Major></FirmwareVer><ErrorList><Kind><ID>E70</ID><Count>1</Count><ErrorLog><BatTemperature>max:0 min:0</BatTemperature><FirstOccurTime>2020.09.06 17:49:38</FirstOccurTime><LastOccurTime>2020.09.06 17:49:38</LastOccurTime><Log><DateTime>2020.09.06 17:49:38</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>000001eb</LensID><ReleaseCount>234</ReleaseCount></Log></ErrorLog></Kind></ErrorList><TotalShoot>3289</TotalShoot><TotalShutter>3</TotalShutter><PowerOnCount>537</PowerOnCount><TotalRunningTime>83180</TotalRunningTime></CameraInfo></Canon>
-
Thanks, looks like your camera was crashed before…
I’m wondering about the BatTemperature = 0.
Do you use external power supply?
And on R5 is a TotalShoot and TotalShutter count...
-
Ran on my R6:
<?xml version="1.0"?><Canon><CameraInfo><Serial>XXXXXXXXXXXX</Serial><FirmwareVer><Internal>0.4.0.5</Internal><Major>1.1.0</Major></FirmwareVer><ErrorList><Kind><ID>E01</ID><Count>2</Count><ErrorLog><BatTemperature>max:0 min:0</BatTemperature><FirstOccurTime>2020.09.17 02:08:57</FirstOccurTime><LastOccurTime>2020.09.17 02:09:15</LastOccurTime><Log><DateTime>2020.09.17 02:09:15</DateTime><Reason>DS-EID:068</Reason><BatTemperature>0</BatTemperature><LensID>0000bc95</LensID><ReleaseCount>528</ReleaseCount></Log><Log><DateTime>2020.09.17 02:08:57</DateTime><Reason>DS-EID:068</Reason><BatTemperature>0</BatTemperature><LensID>0000bc95</LensID><ReleaseCount>527</ReleaseCount></Log></ErrorLog></Kind><Kind><ID>E70</ID><Count>4</Count><ErrorLog><BatTemperature>max:0 min:0</BatTemperature><FirstOccurTime>2020.09.17 13:12:17</FirstOccurTime><LastOccurTime>2020.09.20 12:55:27</LastOccurTime><Log><DateTime>2020.09.20 12:55:27</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>00000000</LensID><ReleaseCount>1171</ReleaseCount></Log><Log><DateTime>2020.09.20 12:51:18</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>00000000</LensID><ReleaseCount>1171</ReleaseCount></Log><Log><DateTime>2020.09.17 13:30:36</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>0000bca9</LensID><ReleaseCount>561</ReleaseCount></Log><Log><DateTime>2020.09.17 13:12:17</DateTime><Reason>DS-EID:101</Reason><BatTemperature>0</BatTemperature><LensID>0000bca9</LensID><ReleaseCount>561</ReleaseCount></Log></ErrorLog></Kind><Kind><ID>E255</ID><Count>2</Count><ErrorLog><BatTemperature>max:0 min:0</BatTemperature><FirstOccurTime>2020.09.20 12:51:15</FirstOccurTime><LastOccurTime>2020.09.20 12:51:15</LastOccurTime><Log><DateTime>2020.09.20 12:51:15</DateTime><Reason>DS-EID:028</Reason><BatTemperature>0</BatTemperature><LensID>00000000</LensID><ReleaseCount>1171</ReleaseCount></Log><Log><DateTime>2020.09.20 12:51:15</DateTime><Reason>DS-EID:028</Reason><BatTemperature>0</BatTemperature><LensID>00000000</LensID><ReleaseCount>1171</ReleaseCount></Log></ErrorLog></Kind></ErrorList><TotalShoot>1471</TotalShoot><TotalShutter>305</TotalShutter><PowerOnCount>311</PowerOnCount><TotalRunningTime>63758</TotalRunningTime></CameraInfo></Canon>
Ran on m50:
<?xml version="1.0"?><Canon><CameraInfo><Serial>XXXXXXXXXX</Serial><FirmwareVer><Internal>0.7.0.0</Internal><Major>1.0.2</Major></FirmwareVer><ErrorList></ErrorList><TotalShoot>1078</TotalShoot><TotalShutter>1078</TotalShutter><TotalSW2>1229</TotalSW2><TotalSW2Long>0</TotalSW2Long><PowerOnCount>690</PowerOnCount><TotalRunningTime>225948</TotalRunningTime></CameraInfo></Canon>
And on R5 is a TotalShoot and TotalShutter count...
It's probably because there is a mechanical shutter and electronic shutter.
-
It's probably because there is a mechanical shutter and electronic shutter.
But it is also on R5
M50 has also an TotalSW2 count...
-
RP:
<?xml version="1.0"?>
<Canon>
<CameraInfo>
<Serial>xxxxxxxxxxxx</Serial>
<FirmwareVer>
<Internal>0.3.8.7</Internal>
<Major>1.5.0</Major>
</FirmwareVer>
<ErrorList></ErrorList>
<TotalShoot>1780</TotalShoot>
<TotalShutter>1086948659</TotalShutter>
<PowerOnCount>229</PowerOnCount>
<TotalRunningTime>148394</TotalRunningTime>
</CameraInfo>
</Canon>
Shutter count seems to be invalid.
-
RP:
Shutter count seems to be invalid.
In this case, yes.
But not in the other examples.
-
Script for getting a list of some known memory ranges, discussed in this thread (https://www.magiclantern.fm/forum/index.php?topic=5071.0) and elsewhere. Sadly, this eventproc is no longer available on R6 (and probably R5), memory handling seems to have been reworked on those new models.
private sub Initialize()
ExecuteEventProcedure("smemShowFix")
dumpf()
end subThe output of smemShowFix can be found in the log.
For example, sx740 outputs this (text needs cleaning as unprintable characters are in it and newlines are missing sometimes):
1993: 1320.904 [RSC] --- Common Lower ----
1994: 1320.934 [RSC] LIME_HEAP 0x00000000 0x00000000 0 [Cacheable!
1995: 1320.940 [RSC] DAF_WORK 0x00000000 0x00000000 0 [Cacheable!
1996: 1320.945 [RSC] DAF_RAW 0x00000000 0x00000000 0 [Cacheable!
1997: 1320.952 [RSC] MOVIE_CFILTER_SEED 0x00000000 0x00000000 0 [Cacheable!
1998: 1320.959 [RSC] OMAR COM 0x00000000 0x00000000 0 [Cacheable!
1999: 1320.964 [RSC] ENGINE_MIRROR 0x00000000 0x00000000 0 [Cacheable!
2000: 1320.970 [RSC] TUNE 0x4046C000 0x001C0000 1835008
2001: 1320.975 [RSC] LIME 0x41800000 0x00500000 5242880
2002: 1320.980 [RSC] NETWORK_HEAP 0x41D00000 0x00300000 3145728
2003: 1320.985 [RSC] ZICO 0x42000000 0x00180000 1572864
2004: 1320.991 [RSC] APROC 0x42180000 0x00021000 135168
2005: 1320.995 [RSC] ARIMA 0x421A1000 0x0006C000 442368
2006: 1321.000 [RSC] SHIRAHAMA 0x4220D000 0x0002E000 188416
2007: 1321.006 [RSC] RENDERING WORK 0x4223B000 0x00CE4000 13516800
2008: 1321.011 [RSC] FILE HEADER 0x42F1F000 0x00100000 1048576
2009: 1321.016 [RSC] FANCING_WORK 0x432CF000 0x001C2000 1843200
2010: 1321.021 [RSC] JOB OBJECT 0x43491000 0x00320000 3276800
2011: 1321.027 [RSC] TUNE2 0x437B1000 0x00160000 1441792
2012: 1321.032 [RSC] SITTERVCODEC WORK 0x43911000 0x00207000 2125824
2013: 1321.038 [RSC] FIX 0x43B95000 0x00170000 1507328
2014: 1321.042 [RSC] DCFNO 0x43D05000 0x00004000 16384
2015: 1321.048 [RSC] DARKCUR_COMP_WORK 0x43D0F000 0x00022000 139264
2016: 1321.053 [RSC] FACTORY/TVAFDEBUG 0x43D0F000 0x00080000 524288
2017: 1321.057 [RSC] VSHADING_COMP_WORK 0x43D31000 0x00027C00 162816
2018: 1321.062 [RSC] CAPTURE_WORK 0x44DB0000 0x015BA800 22784000
2019: 1321.067 [RSC] DANCING 0x7F113000 0x00309800 3184640
2020: 1321.072 [RSC] --- Common Upper ----
2021: 1321.081 [RSC] BITMAP VRAM 0x41100000 0x002F8000 3112960
2022: 1321.086 [RSC] IMG_VRAM1 0x7F41C800 0x003F4800 4147200
2023: 1321.090 [RSC] IMG_VRAM2 0x7F811000 0x003F4800 4147200
2024: 1321.095 [RSC] IMG_VRAM3 0x7FC05800 0x003F4800 4147200
2025: 1321.099 [RSC] --- Normal ----
2026: 1321.128 [RSC] LV_SERVO_WORK 0x00000000 0x00000000 0 [Cacheable!
2027: 1321.134 [RSC] DARK_MEM1_1 0x00000000 0x00000000 0 [Cacheable!
2028: 1321.140 [RSC] DARK_MEM1_2 0x00000000 0x00000000 0 [Cacheable!
2029: 1321.146 [RSC] WORK_HILLTON_1 0x00000000 0x00000000 0 [Cacheable!
2030: 1321.151 [RSC] WORK_HILLTON_2 0x00000000 0x00000000 0 [Cacheable!
2031: 1321.157 [RSC] LV_AE_WORK 0x43B18000 0x0007D000 512000
2032: 1321.163 [RSC] LV_SERVO_WORK_L 0x43D90000 0x01020000 16908288
2033: 1321.167 [RSC] EXMEM3_AREA 0x4636A800 0x02235800 35870720
2034: 1321.173 [RSC] ALGS_AREA_1L 0x485A0000 0x02340000 36962304
2035: 1321.177 [RSC] ALGS_AREA_2L 0x4A8E0000 0x02340000 36962304
2036: 1321.183 [RSC] DIGEST_STREAM 0x4A8E0000 0x05340000 87293952
2037: 1321.187 [RSC] EXALGS_AREA_L 0x512A0000 0x00010000 65536
2038: 1321.193 [RSC] CAPMEM1_AREA_L 0x512B0000 0x02340000 36962304
2039: 1321.198 [RSC] TWAIN_AREA_L 0x535F0000 0x002B0000 2818048
2040: 1321.203 [RSC] DECMEM1_AREA_L 0x538A0000 0x02340000 36962304
2041: 1321.208 [RSC] DIGEST_RECWORK 0x538A0000 0x0871E000 141680640
2042: 1321.212 [RSC] SS_L 0x55BE0000 0x05040000 84148224
2043: 1321.217 [RSC] YUV 1st_L 0x5AC20000 0x029F0000 43974656
2044: 1321.222 [RSC] WORK_GAIN_MAP 0x5AC2A000 0x021EEC80 35581056
2045: 1321.226 [RSC] YUV 2nd_L 0x5D610000 0x029F0000 43974656
2046: 1321.231 [RSC] SS_U 0x60000000 0x05040000 84148224
2047: 1321.236 [RSC] YUV 2nd_U 0x65040000 0x029F0000 43974656
2048: 1321.242 [RSC] YUV 1st_U 0x67A30000 0x029F0000 43974656
2049: 1321.247 [RSC] SUSANYUV 0x6A420000 0x0309B000 50966528
2050: 1321.253 [RSC] DECMEM1_AREA_U 0x6D4BB000 0x02340000 36962304
2051: 1321.258 [RSC] CAPMEM1_AREA_U 0x6F7FB000 0x02340000 36962304
2052: 1321.264 [RSC] TWAIN_AREA_U 0x71B3B000 0x002B0000 2818048
2053: 1321.269 [RSC] YUV Thumb 0x71DF0000 0x02170000 35061760
2054: 1321.274 [RSC] ALGS_AREA_1U 0x73F60000 0x02340000 36962304
2055: 1321.279 [RSC] ALGS_AREA_2U 0x762A0000 0x02340000 36962304
2056: 1321.284 [RSC] EXALGS_AREA_U 0x7CC60000 0x00010000 65536
2057: 1321.289 [RSC] EXMEM3_AREA_2 0x7CC70000 0x014A0000 21626880
2058: 1321.294 [RSC] LV_SERVO_WORK_U 0x7E210000 0x00E20000 14811136
2059: 1321.303 [RSC] --- Movie ----
2060: 1321.312 [RSC] CINEMA_FILTER_WORK 0x00000000 0x00000000 0 [Cacheable!
2061: 1321.317 [RSC] MOVIE_RECYUV 0x00000000 0x00000000 0 [Cacheable!
2062: 1321.322 [RSC] AUDIO WORK 0x41426000 0x00241400 2364416
2063: 1321.327 [RSC] MOVIE_STREAM 0x485A0000 0x04D00000 80740352
2064: 1321.332 [RSC] MOVIE_STREAM 0x485A0000 0x04D00000 80740352
2065: 1321.336 [RSC] MOVIE_RECWORK 0x4D2A0000 0x10910000 277938176
2066: 1321.341 [RSC] 4K_LINEVRAM 0x60000000 0x0B1FA800 186624000
2067: 1321.345 [RSC] LV_WORK 0x63B60000 0x0C270000 203882496
2068: 1321.349 [RSC] --- Play ----
2069: 1321.357 [RSC] JPEG_WORK_4K 0x00000000 0x00000000 0 [Cacheable!
2070: 1321.362 [RSC] SLIDE_SHOW_WORK 0x512B0000 0x01FA4000 33177600
2071: 1321.366 [RSC] IMGPLAY_WORK 0x5A6FE800 0x04C00000 79691776
2072: 1321.371 [RSC] MOVIE_PLAYWORK 0x63B60000 0x10840000 277086208
2073: 1321.375 [RSC] --- Multishot ----
2074: 1321.397 [RSC] HDR/GIS_WORK1 0x00000000 0x00000000 0 [Cacheable!
2075: 1321.402 [RSC] HDR/GIS_WORK2 0x00000000 0x00000000 0 [Cacheable!
2076: 1321.407 [RSC] HDR/GIS_WORK3 0x00000000 0x00000000 0 [Cacheable!
2077: 1321.413 [RSC] HDR/GIS_WORK4 0x00000000 0x00000000 0 [Cacheable!
2078: 1321.418 [RSC] HDR/GIS_COMP_WORK 0x00000000 0x00000000 0 [Cacheable!
2079: 1321.424 [RSC] HDR/GIS_SS-1 0x00000000 0x00000000 0 [Cacheable!
2080: 1321.431 [RSC] HDR/GIS_YUV 1st-1 0x00000000 0x00000000 0 [Cacheable!
2081: 1321.436 [RSC] HDR/GIS_YUV 2nd-1 0x00000000 0x00000000 0 [Cacheable!
2082: 1321.441 [RSC] HDR/GIS_EXMEM3_AREA 0x00000000 0x00000000 0 [Cacheable!
2083: 1321.447 [RSC] HDR/GIS_SS-2 0x00000000 0x00000000 0 [Cacheable!
2084: 1321.452 [RSC] HDR/GIS_YUV 1st-2 0x00000000 0x00000000 0 [Cacheable!
2085: 1321.458 [RSC] HDR/GIS_YUV 2nd-2 0x00000000 0x00000000 0 [Cacheable!
2086: 1321.463 [RSC] HDR/GIS_YUV Thumb 0x00000000 0x00000000 0 [Cacheable!
2087: 1321.469 [RSC] HDR/GIS_MOVIE_RECWORK 0x00000000 0x00000000 0 [Cacheable!
2088: 1321.474 [RSC] HDR/GIS_AUDIO WORK 0x00000000 0x00000000 0 [Cacheable!
2089: 1321.479 [RSC] HDR/GIS_MOVIE_STREAM 0x00000000 0x00000000 0 [Cacheable!
2090: 1321.484 [RSC] HDR/GIS_MOVIE_PLAYWORK 0x00000000 0x00000000 0 [Cacheable!
2091: 1321.489 [RSC] HDR/GIS_4K_LINEVRAM 0x00000000 0x00000000 0 [Cacheable!
2092: 1321.495 [RSC] HDR/GIS_IMGPLAY_WORK 0x00000000 0x00000000 0 [Cacheable!
2093: 1321.501 [RSC] HDR/GIS_SLIDE_SHOW_WORK 0x00000000 0x00000000 0 [Cacheable!
2094: 1321.506 [RSC] HDR/GIS_LV_WORK 0x00000000 0x00000000 0 [Cacheable!
2095: 1321.512 [RSC] HDR/GIS_MOVIE_RECYUV 0x00000000 0x00000000 0 [Cacheable!
2096: 1321.518 [RSC] HDR/GIS_SUSAN_YUV 0x00000000 0x00000000 0 [Cacheable!
2097: 1321.524 [RSC] HDR/GIS_KAITO_YUV 0x00000000 0x00000000 0 [Cacheable!
2098: 1321.529 [RSC] HDR/GIS_LV_SERVO_WORK 0x00000000 0x00000000 0 [Cacheable!
2099: 1321.535 [RSC] HDR/GIS_DANCING_WORK 0x00000000 0x00000000 0 [Cacheable!
2100: 1321.540 [RSC] HDR/GIS_IMGVRAM 0x00000000 0x00000000 0 [Cacheable!
2101: 1321.546 [RSC] HDR/GIS_JPEG_WORK 0x00000000 0x00000000 0 [Cacheable!
2102: 1321.551 [RSC] HDR/GIS_EXMEM3_2 0x00000000 0x00000000 0 [Cacheable!
2103: 1321.557 [RSC] HDR/GIS_FLEXIBLE_MEM3_1 0x00000000 0x00000000 0 [Cacheable!
2104: 1321.562 [RSC] HDR/GIS_FLEXIBLE_MEM3_2 0x00000000 0x00000000 0 [Cacheable!
2105: 1321.567 [RSC] --- Indev ----
2106: 1321.583 [RSC] INDEV_SS-1 0x00000000 0x00000000 0 [Cacheable!
2107: 1321.588 [RSC] INDEV_YUV 1st-1 0x00000000 0x00000000 0 [Cacheable!
2108: 1321.593 [RSC] INDEV_YUV 2nd-1 0x00000000 0x00000000 0 [Cacheable!
2109: 1321.597 [RSC] INDEV_BASIC 0x00000000 0x00000000 0 [Cacheable!
2110: 1321.603 [RSC] INDEV_SS-2 0x00000000 0x00000000 0 [Cacheable!
2111: 1321.607 [RSC] INDEV_YUV 1st-2 0x00000000 0x00000000 0 [Cacheable!
2112: 1321.612 [RSC] INDEV_YUV 2nd-2 0x00000000 0x00000000 0 [Cacheable!
2113: 1321.617 [RSC] INDEV_YUV Thumb 0x00000000 0x00000000 0 [Cacheable!
2114: 1321.622 [RSC] INDEV_SUSAN_YUV 0x00000000 0x00000000 0 [Cacheable!
2115: 1321.627 [RSC] INDEV_KAITO_YUV 0x00000000 0x00000000 0 [Cacheable!
2116: 1321.633 [RSC] INDEV_MOVIE_REC_YUV 0x00000000 0x00000000 0 [Cacheable!
2117: 1321.638 [RSC] INDEV_EXMEM3_AREA 0x4636A800 0x03C95800 63526912
2118: 1321.643 [RSC] INDEV_SLIDE_SHOW_WORK 0x512B0000 0x01FA4000 33177600
2119: 1321.648 [RSC] INDEV_IMGPLAYWORK 0x5A6FE800 0x04C00000 79691776
2120: 1321.653 [RSC] INDEV_WORK 0x63B53800 0x099C6000 161243136
2121: 1321.658 [RSC] INDEV_YUV_IN 0x6D519800 0x02671800 40310784
2122: 1321.662 [RSC] INDEV_YUV_OUT 0x6FB8B000 0x02671800 40310784
2123: 1321.667 [RSC] INDEV_TRIMING_VIEW_WORK 0x72200000 0x02200000 35651584
2124: 1321.672 [RSC] INDEV_EXMEM3_AREA 0x78000000 0x06110000 101777408
2125: 1321.677 [RSC] --- DP ----
2126: 1321.689 [RSC] DP_SS-1 0x00000000 0x00000000 0 [Cacheable!
2127: 1321.694 [RSC] DP_YUV 1st-1 0x00000000 0x00000000 0 [Cacheable!
2128: 1321.699 [RSC] DP_YUV 2nd-1 0x00000000 0x00000000 0 [Cacheable!
2129: 1321.704 [RSC] DP_YUV_IN 0x00000000 0x00000000 0 [Cacheable!
2130: 1321.709 [RSC] DP_YUV_OUT 0x00000000 0x00000000 0 [Cacheable!
2131: 1321.714 [RSC] DP_MULTI_CHUNK 0x00000000 0x00000000 0 [Cacheable!
2132: 1321.719 [RSC] DP_WORK 0x00000000 0x00000000 0 [Cacheable!
2133: 1321.724 [RSC] DP_SINGLE_CHUNK 0x00000000 0x00000000 0 [Cacheable!
2134: 1321.729 [RSC] DP_SS-2 0x00000000 0x00000000 0 [Cacheable!
2135: 1321.733 [RSC] DP_YUV 1st-2 0x00000000 0x00000000 0 [Cacheable!
2136: 1321.739 [RSC] DP_YUV 2nd-2 0x00000000 0x00000000 0 [Cacheable!
2137: 1321.743 [RSC] DP_YUV Thumb 0x00000000 0x00000000 0 [Cacheable!
2138: 1321.749 [RSC] DP_SLIDE_SHOW_WORK 0x00000000 0x00000000 0 [Cacheable!
2139: 1321.754 [RSC] DP_SUSAN_YUV 0x00000000 0x00000000 0 [Cacheable!
2140: 1321.758 [RSC] DP_KAITO_YUV 0x00000000 0x00000000 0 [Cacheable!
2141: 1321.763 [RSC] DP_MOVIE_REC_YUV 0x00000000 0x00000000 0 [Cacheable!
-
Hey Srsa that script worked on the R6.
It's a logfile of 170KB. Is this log file publically shareable?
-
Hey Srsa that script worked on the R6.
I used ExecuteEventProcedure to avoid crashing cameras that don't have smemShowFix. As I mentioned, the R6 is missing that event procedure. Your log is therefore only a regular log without memory range info.
It's a logfile of 170KB. Is this log file publically shareable?
These logs are regularly shared in this forum, so I guess yes. But in this case, it would be pointless.
The R6 1.0.1 firmware has a list of memory range names (list of pointers is located at 0x7A3C in RAM, the firmware has references to 0x7A2C in case you have a disassembly to look at). But, I could not find an equivalent of smemShowFix from a quick look.
-
SX740 picture posted over here (https://www.magiclantern.fm/forum/index.php?topic=5071.msg231082#msg231082).
The R5/R6 don't have smemShowFix, but they seem to have some similar strings, like USER_BMPVRAM, USER_IMGVRAM_1, USER_MOVIE_REC_WORK_2, USER_DAF_RAW and many others:
strings gang100.bin |grep '^USER_'
The routine referencing these strings is likely the equivalent of smemShowFix.
-
Now if someone could figure out if it is possible to disable focus box on M50 to get clean HDMI.
That was done on M100:
https://chdk.setepontos.com/index.php?topic=13489.msg140442;topicseen#new
-
Would it be possible to switch off the automatic crop mode with Canon Basic if Caonon EFS lenses are connected?
-
Probably if we knew all of the right stubs and what to enable/disable. Canon basic seems powerful. I'm still learning but don't count on it because I'm noob.
-
You can write to any memory location by using Poke32 / Poke16 / Poke8, so in theorey it is possible to modify canon code in RAM like that. We only need to find the code locations.
Are you able to revert autocrop when EF-S lens is mounted or is that option locked then?
-
I don't have an R yet myself, but the menu is locked with EF-S lenses. This is not a problem with Sigma lenses. The EF-S 55-250 works really well with the 6d with intermediate rings.
-
I wonder about the increase in TotalShoot and TotalShutter counters.
I have an EOS R that I bought used a year ago.
The seller told me that he took approx 1800 images and I have taken approx 1500 pictures and 300 videos.
Those counters now look like this:
<TotalShoot> 33991 </TotalShoot>
<TotalShutter> 3275 </TotalShutter>
I don’t think the previous owner would have taken over 30000 photos in such a short time.
-
So far confirmed to exist on:
PowerShot SX740
EOS M50
EOS R, RP, R5, R6
EOS 250D
Works as well on EOS M6 Mk2, G5X Mark II and 90D.
-
What about the T8i?
-
Should work but nobody tried and reported back. So: No confirmation.
-
RP:
Shutter count seems to be invalid.
My RP:
<TotalShoot>66947</TotalShoot>
<TotalShutter>1086997532</TotalShutter>
<PowerOnCount>1630</PowerOnCount>
<TotalRunningTime>623795</TotalRunningTime>
To All:
In such way you ran script on R6
-
My RP:
...
<TotalShutter>1086997532</TotalShutter>
...
When subtracting the offset we have found earlier (1086947309) your real TotalShutter count is 50223.
It would be interesting to see the output from another fresh RP with 0 shots taken to confirm that offset. But so far it looks good to me.
-
Hello, and thanks to everyones work!
I bought a "new" Canon EOS RP yesterday, but related to the .xml information (using kitors image), im not sure about ...
Might been tested in store?
<?xml version="1.0"?>
<Canon><CameraInfo>
<Serial>xxx</Serial>
<FirmwareVer><Internal>0.3.9.5</Internal><Major>1.6.0</Major></FirmwareVer>
<ErrorList></ErrorList>
<TotalShoot>701</TotalShoot>
<TotalShutter>1086947603</TotalShutter>
<PowerOnCount>173</PowerOnCount>
<TotalRunningTime>46886</TotalRunningTime>
</CameraInfo></Canon>
1086947603-1086947309=294
Took 6 pictures before the readout. Maybe 1086947609 is the magic number?
Edit: nvm, been confused :D
But what about its PowerOnCount and TotalRunningTime :-\
Greetings ...
-
We don't know much about RP yet, nobody can give you a definitive answer. How much do these values go up on every cam due to testing Canon does in the factory? We don't know.
The TotalRunningTime cannot be correct; that would be 5 years continuous running for yours. Someone else was reporting 50 years.
-
We don't know much about RP yet, nobody can give you a definitive answer. How much do these values go up on every cam due to testing Canon does in the factory? We don't know.
IIRC, my M10 and M100 start with 0 shoots.
Also my 6D.
I think the counters are reset at the factory or do not even run.
-
M10 = Digic 6 running PowerShot code
M100 = Digic 7 running PowerShot code
6D = Digic 5 running EOS
-
Already clear. I mean I would have seen a 0 on an M6II.
I would also expect a 0 for an new R.
-
It's a reasonable expectation, it also happens to be demonstrably untrue. What does it mean that new RP don't show 0 via this method of querying it? We don't yet know.
-
What does it mean that new RP don't show 0 via this method of querying it?
I would assume that the goods were returned. ;)
I bought the G7x 3 times. The first two had single-digit releases. The third was 0. The first two were definitely returned goods. Of course, that doesn't mean that the R's is any different.
-
This is very interesting. We knew that TotalShutter on RP is some arbitrary high value. However so far assumption was that TotalShoot (one that counts both normal and electronic shutter shots) counts from zero.
@ j1080 Was your box factory sealed?
@c_joerg - RP is anomaly. Every RP known (i mean tested) had this arbitrarily big value, however I think this is 2nd time we have data from "known shots number, recently unboxed" camera. So far we assume what the "constant" is, if it is constant at all.
There's a chance that some factory function is altering those values during tests (and values are broken), and for whatever reason they are not reset on RP before shipping / reset function itself is broken ;) .
-
I would assume that the goods were returned. ;)
With 1,086,947,603 shutter activations? This seems somewhat implausible to me, though perhaps you're a faster shooter than I am before you return a camera ;)
I also think this camera is likely gently used and returned, but that doesn't explain listed shutter count on RP. Something else is going on. This camera is different in some way with the way it reports this value. Running time is also obviously incorrectly reported. So, can we really trust the other values, even though they look sensible? We just don't understand this camera very well yet.
-
With 1,086,947,603 shutter activations?
No, because of 701 TotalShoot and 173 PowerOnCount
RP is anomaly.
Yes, of course, TotalShutter on RP is anomaly.
-
Oh, I understand now, you were talking about something different to everyone else in the thread. Now my confusion makes sense :)
-
It was understood that we would like to know whether there is a fixed start number for TotalShutter at RP.
For that you would need an unused RP. And I don't think the RP from j1080 is a total new one.
-
Okay, but your comments about different cams, in a Digic 8 and X thread were confusing and don't seem relevant.
From this thread, there are numbers from multiple different cams. All TotalShutter numbers look to have a similar large offset applied. But, does TotalShoot have a different, *smaller* offset applied? How would we know? It's a reasonable assumption that TotalShoot might start at 0, but TotalShutter *clearly doesn't*, so it's also reasonable to doubt that assumption.
Cam1 TotalShoot: 1780
Cam1 TotalShutter: 1086948659
Cam2 TotalShoot: 701
Cam2 TotalShutter: 1086947603
From these numbers it's still entirely possible that RP has an offset of 700 applied to TotalShoot, similar to how it seems to have an offset of approximately 1086947300 applied to TotalShutter. If that was true, j1080s cam would have taken 1 prior shot. Or there could be no offset, and it's taken 701. Or an offset of -10000 and it's real number is 10701. Notably, my 200D (bought new... probably) reported a negative TotalShoot when I first had it!
Likely it will be easier to reverse the firmware to determine the logic, than to prove we have a new cam where we can totally trust the values.
-
Okay, but your comments about different cams, in a Digic 8 and X thread were confusing and don't seem relevant.
Sorry for the confusion.
Since the CameraInfo part is already available in the Powershot firmware, I assumed that this part also ended up in the firmware of the R and was only expanded.
-
Since the CameraInfo part is already available in the Powershot firmware
This was a good point anyway. I was unaware of that coming to us from Powershot world (like Basic did).
reported a negative TotalShoot when I first had it!
Are you sure TotalShoot and not shutter_count_plus_lv_actuations? We have three* different counters, not two!:
On "old" cameras (up to D7, PROP_SHUTTER_COUNTER):
buf[0] -> shutter_count = number of still shots with physical shutter actuations
buf[1] -> shutter_count_plus_lv_actuations = number of physical shutter actuations, including enter/exit LV which does open/close shutter
on "new" cameras (D8+)
PROP_MECHA_COUNTER (TotalShutter) -> equivalent of shutter_count*
PROP_RELEASE_COUNTER (TotalShoot) -> above + number of silent pictures (with no physical shutter actuations)
I believe you write about shutter_count or shutter_count_plus_lv_actuations, not TotalShoot.
*We still need to confirm that on D8 DSLR, as either:
- PROP_MECHA_COUNTER is equivalent of shutter_count_plus_lv_actuations and not shutter_count (would make sense by prop name)
- there's additional prop that is equivalent of one "missing" on D8, which is missing just on mirrorless
-
So there might be something weird going on with the TotalShutter integer type of the RP's firmware versions.
@names_are_hard Wasnt expecting that, just mentioned as i didnt belive that its brandnew and been wondering about those numbers.
TotalRunningTime is reported in seconds, tested that, but still 13+ hours.
@kitor The box itself wasnt sealed, but all the items inside. The body itself had a packaging with some kind of aluminium-sticker on it.
I dont belive its new, even if sold as.
-
Don't know why I had it in my brain as hours, seconds does make a lot more sense! Basically, for the RP, we don't really know what these numbers mean. There are some fields where we can make some obvious guesses, and likely be right, but that's about it.
Don't recall which precise field it is for 200D, point being, it was negative so I don't put it past them to apply a negative offset to one of the other fields (plus code for some existing cams already applies a fix for this, I've seen it somewhere).