Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - kitor

Pages: [1] 2 3 ... 5
Camera-specific discussion / Re: Canon EOS R / RP
« on: May 18, 2019, 11:17:17 PM »
is there somebody, who is still working on ML for Canon EOS R?  >:(

Refer to this. No posts = no news.

f. e. Intervalometer, Motion detection,
So we have something in common (had to bring notebook with me last time I suddenly needed intervalometer). However I risked a lot to my camera (as seen in this thread) to at least try to make it happen.

Change PAL/NTSC region in camera.

Camera-specific discussion / Re: Canon EOS R / RP
« on: May 05, 2019, 07:26:20 PM »
Up to now, mostly like you described.
Is it a hunt for the memory addresses than respond to the things we need. LED at address xxxxxxx, memory for sensor data at xxxxxx ??

But not only for hardware memory addresses, but also for location of needed DryOS functions that we need to call. In 'normal' programming you just include headers for some library and use it. Here you need to find that stuff in disassembled ROM first, understand how it works, what parameters it can take (and thus how to call it). This is already mostly done with previous cameras, so you just need to find proper memory location that holds your needed function. Later also find how to 'hook' into Canon tasks to get data from them, etc.

And DryOS (and low level stuff - new Digic processors) changes with time. That's why Alex did 'fishy' M50 port that allows ML menu access, but it breaks things for older devices so he decided not to push code until he sorts this out.

Build a development environment, startup QEMU, dump ROM files and make your first steps inside the emulator.
Tutorials how to make QEMU run are available.

Walter, I see a similar post from time to time.
Unfortunately (from few years experience working with developers (!, so people who should know the drill) in quite large project), I don't think people who ask those questions does understand problem at all.

For average person installing software on new PC is like... download it and install. They think that the problem is that with their new camera no one yet tried to download and install ML and provide feedback that it works (yup, I'm oversimplifying, but again, experience tells me to expect low unless proven wrong).

We know that ML code doesn't grow on trees. (great quote btw!). But this means nothing even for pro photo/videographers who used ML for living, if they don't have any computer engineering background.

IMO, the real answer should be like:

Quote from: kitor's alter ego
Unless you know or want to learn how to do any of this, wait patiently for news containing download links, or grab a camera that is supported now.

Sorry for OT, but something tells me this post may be much better answer for all people asking.

Camera-specific discussion / Re: Canon EOS R / RP : new FIR version
« on: May 04, 2019, 02:39:32 PM »
As soon as debugging EOS R or RP will be possible within QEmu, I'll continue my investigations started with Alex. He owns holidays after giving years of time to ML.
There is a patch for M50 here; IIRC it worked on R with minimal changes. Will clean them up for committing, but I think it will happen after bringing the current state into mainline.

I'm not competent enough to do those 'minimal changes' myself unfortunately, at least not without any hints where to look.

Camera-specific discussion / Re: Canon EOS R / RP
« on: May 04, 2019, 02:15:42 PM »
A bit of ML offtopic:

1.2.0 seems to remove banding issues:
Ladies and Gentlemen! WE HAVE DONE IT!! Thank you so much to the many of you who gave feedback, shared my videos, posted in forums and relayed the information you received from Canon, I can confirm that Firmware update 1.2.0 resolves the banding issue I reported back in November on the Canon EOS R!

Tamron 70-200 G2 works great with R
Tired of waiting for RF 70-200 (and in need for one soon) I wanted to pick used 2.8L IS II USM. But found that Tamron presented not so long ago 2nd gen of their lineup (and new SP 70-200mm F/2.8 Di VC USD G2 is roughly the same price as used 2.8L IS II). As I have good contact with one camera store, I played a little with this lens via basic EF-RF adapter and it worked flawlessly, AF was fast and accurate, no problems with VR (shots like 1/30 on 200mm).
Interesting (and not found in manual) feature is that tripod mount will mount directly to Arca Swiss compatibile Quick Releases, what I found by accident.

Sample full-res jpeg (from raw, without LR lens corrections; 200mm/2.8 ISO 100):
This is how this combo looks:

As for missing control ring on EF lenses, I'm using back-button focus, thus I have exposure lock on half-shutter. So i set exp-lock button + upper dial as ISO change. Works much better than fighting with touch bar and saves a lot of money on adapter with control ring.

Reverse Engineering / Re: Battery grip pins / UART
« on: May 01, 2019, 01:00:42 PM »
For upcoming RP I expect the same.
Note that R (and RP on mentioned photo) has 2nd similar connector next to this one. No communication was visible, something tells me this may be JTAG. However not accessible without disassembling camera.

A few more hide behind the button pad rubber which needs to peeled away, also like the EOS R.
Hole to UART connector is clearly visible. From board photos seems that only one of two connectors was left (lower one), unfortunately testpads positions suggests they may be hardly/not accessible through that hole, so proper FPC cable will be needed.

Code: [Select]
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l

As for lime strings, from EOS R:
Code: [Select]
"Error : bad parameter(LimeClock).":
"Inport(CCLIME_TIC_WDLPS_ADDR) == val":
"Inport(CCLIME_TIC_WDLP_EN_ADDR) == val":


"[NWCOM] Lime Load Complete For XDmac(Ch=%d)":
"[NWCOM] Lime Load Complete For CPU":
"[NWCOM] LimePanic":
"[NWCOM] LimeExcept":
"[NWCOM] LimeAssert":
"[NWCOM] Lime WorkLoad CPU":
"[NWCOM] Lime WorkLoad (DMA)->CPU":
"[NWCOM] Lime Init":
"[NWCOM] Lime Uninit":
and more. So seems to be related to WiFi / SDIO is used for WiFi card internally (that's interesting)

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 28, 2019, 12:55:12 PM »
Oh, Hai!

I don't understand this at all. Seems that dump_file shifts down ram offsets by 0X10?! explanation below
bmp_vram_info sits at 0xFB2C, not 0xFB1C. How I found this?

Code: [Select]
for(uint32_t * i = 0x40000000; i < 0x80000000; i+=1){
        if(*i == 0x412ff900) uart_printf("vram1 %p \n", i);
        if(*i == 0x414ff400 ) uart_printf("vram2 %p \n", i);

and a few moments later
Code: [Select]
vram1 0x4000fb2c
vram2 0x4000fb30
vram2 0x4000fb34

But what's werid MARV structures sits exactly where I found them in a dump:

Code: [Select]
bmp_vram_info 0xfb2c
bmp_vram_info[0] 0x412ff900
vram1 0x412ff900
vram2 0x414ff400
back_vram 0x414ff400

yup, that's shows my desperation  8)

@dfort - new MR coming in a moment :)

OK, now I know what happened. Our initial dump on 1.1.0 has been shifted. I got MARVs from new dump, bmp_vram_info I was checking on old one all the time... working on pointers at 2AM is a bad idea.

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 28, 2019, 12:00:03 AM »
Got another RAM dump and this makes sense, those are buffers I drawn into myself (dump starts from 0x40000000):

Code: [Select]
kitor@kitor-pc:Desktop$ xxd -e -s 0x0000FB1C -l 0x0C RAM.BIN     #bmp_vram_info
0000fb1c: 412ff900 414ff400 414ff400           ../A..OA..OA      #vram1, vram2, back_vram

kitor@kitor-pc:Desktop$ xxd -e -s 0x002ff900 -l 0x2C RAM.BIN    #MARV for 2ff900
002ff900: 5652414d 41100100 00000000 11060200  MARV...A........
002ff910: 00000400 000002aa 412ff91c 4d454d50  ........../APMEM
002ff920: 00000010 00000000 41100000           ...........A

kitor@kitor-pc:Desktop$ xxd -e -s 0x004ff400 -l 0x2C RAM.BIN    #MARV for 4ff400
004ff400: 5652414d 412ffc00 00000000 11060200  MARV../A........
004ff410: 00000400 000002aa 414ff41c 4d454d50  ..........OAPMEM
004ff420: 00000010 00000000 412ffadc           ........../A

So the problem seems to be somewhere deeper, as LV hangs (and ML throws exception) directly on bmp_vram_raw() call

[e] I don't understand something:

Code: [Select]
  uart_printf("bmp_vram_info %p \n", bmp_vram_info);
    uart_printf("bmp_vram_info[0] %p \n", bmp_vram_info[0]);
    uart_printf("vram1 %p \n", bmp_vram_info[0].vram1);
    uart_printf("vram2 %p \n", bmp_vram_info[0].vram2);
    uart_printf("back_vram %p \n", bmp_vram_info[0].back_vram);
    uart_printf("bmp_marv, should match above %p \n", bmp_marv());

Code: [Select]
bmp_vram_info 0xfb1c
bmp_vram_info[0] 0x1
vram1 0x1
vram2 0x4fc0278
back_vram 0x41100000
bmp_marv, should match above 0x1

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 11:22:50 PM »
Nevermind, tried to create PR from master repo instead of mine  :'( But I'll wait a bit, since...

In the meantime I traced the problem to bmp_vram_info. I was able to hand-draw some lines on display using code from here:
and display buffers from RAM dump: 1100100 12ffc00

No related picture as I was too lazy to make one, however now I understand mostly that this structure holds addresses of both buffers
Code: [Select]
struct bmp_vram_info
    struct MARV * vram1;        /* one of the two bitmap buffers - statically allocated? */
    struct MARV * vram2;        /* the other bitmap buffer */
    struct MARV * back_vram;    /* we need to write to the other one */

but I still don't know how to find this pointer from stubs.C / how Alex got one:
Code: [Select]
/** Bitmap **/
DATA_PTR(    0xFB1C,  bmp_vram_info)
Funny enough, when set to exactly the same value as on M50 LV won't crash, but drawing won't work either.
DATA_PTR is relative to RAM?

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 09:04:02 PM »
At least I was able to get firmware signature updated and collect stack dump for Alex when he's back.

Would create MR, however I don't have rights for official repo...

Is there any built-in way to send some prints to log on card? Without qemu and still no display, UART using needle (literally as I still don't have proper cable) is quite annoying...

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 08:13:30 PM »
It probably locked due to firmware signature not corresponding.
And bingo! After skipping check it runs like before (crashes LV). Added some blinking, LV crashes on bmp_vram_raw() as I have 4 blinks and then crash :)
Code: [Select]
static void hello_world()

    while (!bmp_vram_raw())

        font_draw(100, 75, COLOR_WHITE, 3, "Hello, World!");

Unfortunately when tracing bmp_vram_raw() i saw dark magic :(

$1300+ (around 5000 PLN) is usually for camera, battery and charger with "less than 150k count". Box with accesories 5500 and up
I paid for mine 3300 PLN for complete box, extra batteries and cards. Shutter replacement is about 1000 PLN. So I can replace it twice before I hit usual price
Average net salary in Poland is about 3200/month. Profitability depends on PoV :) So that's up to OP's mind if price gap is big enough in his country

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 01:59:06 PM »
Hmm, I was sure that digic6 branch had no signature testing. At least it was the case at some moment just when 1.1.0 update arrived ;)

Then I'll remove signature check as I don't have qemu working for R yet (got path from Alex for m50, however this needs mods for R), and on-camera computation won't work at the moment (guess why :) )

Not so long ago I bought one with 350k count for roughly the same price.

If you're going to use it for filming, IMO just check shutter/mirror if it works properly. Easiest method I know it to simply run a long series of properly exposed photos on 1/8000 shutter and look for any signs of shutter/mirror not moving fast enough (visible in exposed frame). And of course check sensor for defects (again, simplest method - iso 100, 30s exposure with closed lens cap and any noise cancelation disabled in menu)

Don't know for how much 5D3 retails in your country, here in Poland is $1300+ equivalent with "normal" counts and shutter replacement in authorized service costs less than $300 eq., so the math was easy for me  :)

Of course I wound't take any job with high shutter count monster without bringing any backup body, but that should apply for any job as even new camera may fail...

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 27, 2019, 08:44:42 AM »
Thanks. Same behavior unfortunately  :(
Time to dig into ML code then.

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 26, 2019, 06:29:44 PM »
Can someone with working toolchain checkout this repo/branch:
and compile for me minimal hello world?

Code: [Select]
cd minimal/hello-world
make MODEL=R

On 1.1.0 hello_world gave me LV crashes instead of text printed, but at least it worked.
Between updating, dumping 1.2.0 and updating stubs I updated my WSL distro (Ubuntu 16.04 to 19.04) and linker stopped working:
Code: [Select]
Using /usr/bin/arm-none-eabi-gcc (from PATH).
[ VERSION  ]   ../../platform/R.120/version.bin
[ CPP      ]
[ LD       ]   magiclantern syntax error
make: *** [../../src/Makefile.src:224: magiclantern] Error 1
indeed is generated broken :(

So i setup toolchain on another machine (this time Debian testing), built it and camera lockups completely, even before any print from ICU on UART:
Code: [Select]
BootLoadNow jump to AUTOEXEC.BIN(0x00800000)!!
//and dead...

ML Rescue as autoexec.bin still works from the same card...

Not sure if that's my toolchain problem or what. For new stubs I even compared them against M50 ROM and I'm sure they are right.

I installed QEMU from qemu branch, however I don't see any definitions for M50 or R here. What do I need to do to emulate those?
Any hacks in arm-softmmu/hw/eos, or I should use some other camera for now?

General Development Discussion / Re: Portable ROM dumper
« on: April 19, 2019, 09:32:22 AM »
If you need dumper for R, I can PM you one (but as autoexec.bin, not .fir), yesterday dumped 1.2.0 firmware so it works  ;).
Still won't work without bootflag enabled via UART.

From my knowledge, FIR encryption on R / RP is still a mystery.

Camera-specific discussion / Re: Canon EOS R / RP
« on: April 14, 2019, 02:21:17 PM »
At the moment it's impossible to run anything without enabling bootflag via UART first. Something like this:

Post-processing Workflow / Re: "LosslessCut" Video Trimmer
« on: April 10, 2019, 07:09:11 PM »
You can achieve that using ffmpeg.

Code: [Select]
ffmpeg -i file.mp4 -ss 02:11:34 -t 00:30:00 -acodec copy -vcodec copy out.mp4not only for mp4, it should also work if you output to different container type (flv, mov) as long as it supports used codec.

Merging multiple files with same container and codec without reencoding is also possible:

Fixing out of sync audio, etc, no problem, one of many possible solutions
Code: [Select]
ffmpeg -i d1.m4v -itsoffset 0.5 -i d1.mp4 -vcodec copy -acodec copy sesjad2.mp4
Replace audio without re encoding video (eg after denoising in audacity, or making it louder): (i'd like to encode fixed audio with same codec params as source, but this is not always needed)
Code: [Select]
ffmpeg -i v.mp4 -i a.wav -c:v copy -map 0:v:0 -map 1:a:0 new.mp4
and much more. Of course no GUI, also remember that you need to round cut to keyframes or you'll get a few black ones at start.
We used those methods to quickly cut, fix, and sync video/audio on OBS recordings from conferences that I live streamed.

Camera-specific discussion / Re: Canon EOS R / RP
« on: March 10, 2019, 01:55:15 PM »
Almost. Standard 0.5mm is too wide, I wasn't able to connect both TX and RX without shorting one of them to next pin (GND). I measured piece of FPC cut to fit into connector and divided into 8 pins, got roughly this 0.4mm pitch.

Camera-specific discussion / Re: Canon EOS R / RP
« on: March 09, 2019, 10:36:43 PM »
If anyone already had his hands on RP and have USB UART that's able to work with 1v8 levels, you may try to dump the bootloader using my previous code.
UART will be probably hidden under thumb rubber, as it has same style connector and very similar location to R.

So far I had no time to play more with R unfortunately.
BTW - if anyone knows where I can get my hands on 0.4mm pitch FFC cable (8 pin is needed for R and probably RP UART), please send me PM. Other devices that may use this internally are also a valid option (to harvest from dead / get spare parts).

Pages: [1] 2 3 ... 5