Menu

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.

Show posts Menu

Messages - calle2010

#1
Camera-specific Development / Re: Canon 80D
August 13, 2019, 03:46:22 PM
Here is the blog that describes why the security update was done by Canon.
https://research.checkpoint.com/say-cheese-ransomware-ing-a-dslr-camera/

Not so surprising, security obviously wasn't the main design goal or quality metric for Canon so far.

The blog mentions Scout debugging tool being loaded into the camera.
https://github.com/CheckPointSW/Scout
Unfortunately not more details are given. I wonder if this could be a good tool for ML porting purposes.
#2
Quote from: alawiggle on May 02, 2019, 07:56:32 PM
Is this normal?

The model detection error comes up if the computed ROM signature doesn't match the one in fw-signature.h. What did you define there?

At least in the digic6-dumper branch in reboot.c if you compile with CONFIG_QEMU=y it will print in Qemu the expected signature. Just put this to fw-signature.h.
#3
I think this is the error if no module was built on install and install_qemu targets.

There's a simple fix for that:

https://bitbucket.org/calle2010/obsolete-magic-lantern/commits/7c425ae2c0d0e17855e4811dcb6ac0ae998dc00f

I think I should create a PR.

Also you can save a lot of time if you add

ML_MODULES=


to your make comand line. It will skip module builds which anyways fail at this stage.
#4
Quote from: jonas18z on May 02, 2019, 01:11:08 PM
beer
...should be avoided 12 hours before posting to a public forum.  :D
#5
Quote from: names_are_hard on April 25, 2019, 12:16:49 AM
There are also xdmac strings, not very many, some are close to some PCIe strings.  I'm not convinced there's a link to edmac, but I'll explore further.

Thank you for sharing the information. Currently I have very little time to spend on ML. I think in May I would try to catch up with the 77D stubs based on yours and also try to understand the EDMAC.
#6
General Chat / Re: The 'when' question
April 24, 2019, 06:43:54 AM
Quote from: dfort on April 24, 2019, 02:47:28 AM
https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/platform/M50.102/

Hey guys sorry if I trolled. If you re-read my post the only important part is: "...where is the "fishy" code and has there been any other update to 1.0.2?"

I know your repository and I did understand your intention. Also I understood that in the "fishy" code there would be important changes applicable to D7 models as well. Is there the nearly finished code for the display, for example?

So I fully agree with what you intended, but not with the words you chose.

#7
General Chat / Re: The 'when' question
April 23, 2019, 05:40:42 PM
Quote from: a1ex on April 23, 2019, 03:34:29 PM
The M50 is in the exact same place I've left it a few days ago. I know, it doesn't seem right, I need to do something to fix it.

I have no idea how the M50 code looks like. Is there anything holding you back from pushing it to an experimental branch with lots of "TODO" comments and leave it to the community to solve these?

If cleaning up the code is beyond the capabilities of anybody else but you, which could well be the case, then ML as a project has a serious issue.
#8
Quote from: a1ex on April 10, 2019, 09:11:36 AM
- why is scrolling in the opposite direction?!

Because this direction is the same as the direction you would use on a touchpad with a two-finger-gesture to move the screen content. See the scroll wheel as a primitive one-dimensional touchpad.

The Windows scroll wheel direction comes from the "I click&drag a scrollbar to move the content" times (1990s or so :) ). The scrollbar moves into the opposite direction (down if the content moves up).
Fortunately my Logitech mouse on Windows can change this weird Windows quirk.
#9
General Development / Re: Bitbucket for Beginners
April 10, 2019, 07:22:36 AM
To merely compare branches you don't need to create a Pull Request (PR) and potentially annoy the upstream repository owner. In the branches view you can select a branch and select compare. The functionality is very similar to creating a PR, without actually doing it.


#10
General Development / Re: Bitbucket for Beginners
April 10, 2019, 07:15:15 AM
Thank you for the tutorial. This should be a sticky.

On good commit messages: https://medium.com/compass-true-north/writing-good-commit-messages-fc33af9d6321

Or simply read commits made by Alex (always something to learn) and take note how he uses commit messages.
#11
A good oppportunity to reprovision my Vagrant environment. The install script works with latest Ubuntu Bionic

arm-none-eabi-gcc: gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1)
gdb-multiarch: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
#12
General Chat / Re: Canon emulator
April 09, 2019, 06:24:40 AM
As far as I understand the ARM CPU emulation is the smallest problem since it is provided by Qemu. All the custom or very specific chips around it are the difficult ones. You'd have to emulate them on the RaspPi as well. And then you'd have to do it in hardware or catch the hardware accesses which is at least as difficult as it is in Qemu.

E. g. the buttons are not directly connected to a GPIO of the main CPU but to the MPU as far as I understand.

For sure it would be a fun project, e g. with a cheap camera module to "simulate" a real camera. But I don't see value for the actual reverse engineering.
#13
Camera-specific Development / Re: Canon 7D Mark II
April 08, 2019, 02:09:46 PM
No, you shouldn't get errors (some warnings are normal).

The issue is with some builds that there are no modules, then the build fails.

For the 77D I solve that by building one random module for another camera model (e. g. arkanoid for 5D3.113). After this I can do the 77D builds with "ML_MODULES=" without errors.

See https://github.com/calle2010/magic-lantern-77d-vagrant#compile-and-run-magic-lantern for examples.
#14
Reverse Engineering / Re: Ghidra scripts
April 07, 2019, 09:24:23 AM
Thank you for this!

Have you seen the latest change to stub.h from A1ex?
https://bitbucket.org/calle2010/magic-lantern/src/6aff5f72ba485652bfd902de0fb1b6fe3480ff0d/include/stub.h?at=digic6-dumper

No guesswork required to know whether it is a data pointer or a function and Thumb or ARM. Also the Thumb bit is handled correctly which removes a source of error.

Would be nice if we could have this in contrib/ghidra or similar.
#15
Quote from: names_are_hard on April 03, 2019, 11:25:41 PM
I made some changes but git push gave me a 403, so I guess I can't submit a pull request?

You could create a PR from your own fork. But you can't directly push to another repository if permissions haven't been setup.

Thank you very much for the edits. I took them over manually. What started as my personal notes for the 77D may turn into a ML Ghidra guide.  :)

QuoteI think you have the "language" wrong, and should be using ARM Cortex 32 little endian, not ARM v7.

I will check this. I though ARM v7 architecture is correct for the Cortex A9 processor? Actually I'm a bit confused by the choices in Ghidra...

QuoteSecond, you shouldn't load each ROM as a file in your Ghidra project (I made this mistake too).  This makes each file separate and disassembly can't see stuff in the other files, so you will get lots of broken refs.  Instead, load the main ROM, then use File -> Add To Program.  This puts all the files in the same address space and disassembly works much better.

Actually this is what I do, but my language was not clear enough.

Quote
Third...  I should really write a Ghidra script that reads stubs.S and disassembles and labels every code address.

...and also for named_functions.idc :-)

Btw: I use F12 always instead of D since the thumb flag is not persisted. In the next session "D" may try to analyze ARM instead of Thumb again. Nearly all code of the 77D seems to be Thumb.
#16
What a serious turn this April 1st thread made.

I'd like to add some Twitter wisdon from Kent Beck:

Quote
If there's one lesson I would like the next generation of developers to learn, it is to spend less time doing hard things and more time making hard things easy. Customers benefit from the former. Customers and peers and we ourselves benefit from the latter.

I think Alex' work is fantastic especially from this point of view. The work on Qemu, documents like HACKING.RST or the M2 walkthrough are more important than another feature for ML on a specific camera.
#17
That's a very good summary. I decided to give up on improving the emulation for now. This task is beyond my knowledge and I think I make no progress:
I tried to create 77D MPU spells but ailed because many important spells are not in the log from my camera and I don't know why.
I tried to analyze and debug the WaitPU1 issue but do not understand enough of DryOS semaphores, sequencers and other things to make any sense of it. I believe this blocks the firmware startup sequence
I have no clue how to fix QEMU for the new display GPU. I thought about having a breakpoint, dumping the VRAM every second to a file and convert and display outside of QEMU...  but as long as the emulation is stuck it doesn't make much sense.

So I think I will follow your path, trying to find the relevant stubs for ML Hello World. As the two models are very similar we should be able to benefit from each other.

I use Ghidra, too.  I wrote a small Getting Started for the 77D ROMs. It should be nearly identical for the other Digic 7 cameras: https://github.com/calle2010/magic-lantern-77d-vagrant/blob/master/ghidra.md
Im happy for feedback and tips since this is the first time I use a tool like this.
#18
Would be great if we could share progress here in the forum and also have the links to our repositories.

Mine is: https://bitbucket.org/calle2010/magic-lantern-77d/commits/all (updated)
I will share whatever is halfway working for me.

I know this one with WIP for 200D: https://bitbucket.org/stephen-e/ml_200d/commits/all

Finally it probably would be good to have pull requests for Alex for any substantial progress.

I'm not very fond of IRC, especially because I think a lot of communication is lost when one is offline. No idea how to stay online for 24h. Is anybody interested in using Slack or similar for chatting? At least for the DIGIC 7 stuff, not as a replacement for IRC.
#19
From what I understand this shows that we can run code on the camera next to Canon's firmware and some people much smarter than I have figured out how to modify the screen buffer.

If you need ML to produce great video then you should not hold your breadth while waiting for it...
#20
hello-world on 77D:







In liveview mode and while recording a movie it blinks once per second. During menu display it gets wiped as soon as a new screen is shown. I think this is expected. Also at shutdown it overlays the sensor clean animation, blinking.
#21
Sounds great, Chris! If there is a need I will try it.

I found one area with 14MB which seems to be pretty stable, even with burst pictures, and three more areas with more than 40MB which should be good for lighter workloads.


/* area at 43700000 doesn't seem to be overwritten by burst pictures */
buf = (void *) 0x43700000           /* 43700000-444FFFFF = 14MB, 4BA00000 - 4E2FFFFF = 41MB, 4E400000 - 50DFFFFF = 42MB, 72A00000 - 753FFFFF = 42MB */
buf_size = 14 * 1024*1024;


I wonder if it is better to use the uncacheable address space, as defined for the 80D? Cause the log is likely to be written from both CPUs.
Still confused by what is cacheable and what not.
#22
Ol, Alex.  I will try again and not use the photobook function either
#23
I played with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP.

With commit 6a3ca36c I get a very clean DEBUGMSG.LOG with only "used/maybe unused" log entries.

I tried it two times. Then I found two memory areas with 6MB each consistently mark as "maybe unused".
Main difference between the two tries was that in the menu I clicked an item to setup a photobook. It seemed to read the pictures on the card (nearly 100 from previous experiments), so this try showed many more memory areas as used.

I'm a bit disappointed that I couldn't find a larger chunk of memory. I think logging will be very limited with only 6MB.

My procedure for the experiment:

Steps:
- put the card with autoexec.bin and close the card door
- wait for the LED to go dark
- start camera in M or P mode, High Speed Shutter enabled
- startup will take a couple of seconds
- wait for three seconds (LED blinks)

Do all of this within 50 seconds:
- open menu and do two or three steps
- take one picture in photo mode
- take one picture in LV mode
- take some seconds of video (in my case 8s video snapshot function since I don't use any other video function)
- go to image playback mode, zoom into one of the photos
- take pictures until buffer is full

- Important: Wait until LED blinks 3/4 times and all pictures are written to the card (may overlap)

Only until LED is dark for a minute:
- Switch off camera
- wait five seconds
- open card door
- wait five seconds
- take card, get DEBUGMSG.LOG

These are the two areas. All others are smaller:

5A400000-5A4FFFFF: maybe unused
5A500000-5A5FFFFF: maybe unused
5A600000-5A6FFFFF: maybe unused
5A700000-5A7FFFFF: maybe unused
5A800000-5A8FFFFF: maybe unused
5A900000-5A9FFFFF: maybe unused

69600000-696FFFFF: maybe unused
69700000-697FFFFF: maybe unused
69800000-698FFFFF: maybe unused
69900000-699FFFFF: maybe unused
69A00000-69AFFFFF: maybe unused
69B00000-69BFFFFF: maybe unused
#24
Thank you, Alex!

Quote from: a1ex on March 27, 2019, 11:11:12 AM
Maybe I'm misunderstanding what TDD is all about ???

I was told in the last millenium that testing takes 10 times longer than development. I guess this hasn't changed. Only that you now can make a machine doing it over and over again, saving us from all the headaches!  :)

I haven't even started to dive into the testing machinery that you built...
#25
Quote from: a1ex on March 25, 2019, 11:32:25 PM
77D FIR for enabling the boot flag: BOOT_77D.FIR

I have loaded BOOT_77D.FIR on an SD card formatted in camera, executed the firmware update process and ... it worked!  ;)





I could compile minimal-d78.c for 77D.102 from commit 537045b7424c and the AUTOEXEC.BIN worked on the camera.

I've got another dump of my ROMs and this output, which must come from call("dumpf"):
https://bitbucket.org/snippets/calle2010/Ke4GB8#file-LOG000.LOG
Camera continued to work while the dumps were made and afterwards...

@Alex: You mentioned that you have a fix for struct fio_file. Are you going to commit this, too?

I guess the next step for 77D is to capture the log files and then try to get Hello, world running?