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.


Topics - names_are_hard

Pages: [1]
1
Just found out the Magiclantern build process has some dependency on Python 2.  I don't know exactly what it is, but on my system, where Python 3 is the default, it fails "make zip".  Plain "make" succeeds.  I think something to do with the nasty way module_strings.h is generated.

Anyway - should somebody with some Python experience want to port the build process to v3, it would be much appreciated.  Python 2 will be unsupported in a month.  It would be a good way for someone to contribute, without needing ARM / Assembly / C experience, but able to build ML by following the instructions.

Mostly I am making this topic so people realise ML is very soon to be dependent on completely unsupported software:
https://pythonclock.org/?1

2
General Development Discussion / ARM assembly, efficient jump hook help?
« on: December 08, 2019, 04:38:41 AM »
I'm trying to patch in some jump hooks for debugging.  I'm finding it hard to work out efficient ARM assembly for this (I'm an ARM noob).  In x86 I'd JMP 0x12345678 and it would be 5 bytes with no register side effects.  ARM I can't set a dword constant in one go.  I'm also in Thumb mode.  Best I have so far is this, which kind of sucks:

        PUSH {R3, R4}
        MOV R4, 0x1234
        MOV R3, 0x5678
        LSL R4, R4, #16
        ADD R4, R3
        BX R4

Which is 18 bytes, feels bad to me.  Some functions I'm interested in are the same size!  Any better way to jump to an arbitrary offset?  Maybe I'd win by swapping out of Thumb first?

Alternatively, any ideas on how to accomplish the same idea efficiently in ARM would be appreciated - patch in a transfer to my own code to do arbitrary stuff, then cleanup register & stack changes and transfer back.

3
I thought I would try and make it easier for people to build Magiclantern.  This is a work in progress and only brave people should help me test - but I do want testers!  This should work on Linux, Mac or Windows 10, I have only tested on Linux.

The idea is we'd only need one set of instructions for building on any OS, and as a bonus everyone would be building with the same build tools, which is nice for debugging problems.  I hope the instructions can be much simpler than the current process.  There are some downsides but I think they're manageable.

To help, you will need git, and be happy to run command-line stuff.  Do this:
git clone https://bitbucket.org/stephen-e/ml_docker_builder
Then follow the instructions in the README.txt.

Please use README.txt (I want feedback on those instructions so that I can improve them).  However, so that people can see what I'm trying to do, the process is like this:

<install docker>
<become root or admin>
<copy-paste the following lines...>
docker build -t ml_build .
docker rm ml_build_output
docker create --name ml_build_output ml_build https://bitbucket.org/hudson/magic-lantern/branch/unified 5D3.113
docker start --attach ml_build_output
docker cp ml_build_output:/home/ml_builder/ml_build/autoexec.bin .

You should now have autoexec.bin.  You can change the repo or camera version to get different autoexec.bin.  It works with both Mercurial and Git repos (but this is pretty crude, I'm sure there are cases I haven't considered).

I *think* that is a fairly easy way to get started building ML?  If it isn't helpful, please let me know.  If there are obvious things that should be added, also let me know. I guess I want some ability to make the zipfile?  I don't know what most people use to create the files they need.

I also don't have a cam that works with ML, so I can't test this is currently a good build.  I know ML can build but with broken output with some compiler versions, etc - at the moment I just want to know if autoexec.bin builds for different people on different OS.  If you want to try the autoexec.bin, that's up to you!  I give no guarantees!

4
I think this affects ML.  Maybe not, they talk about Bitbucket Cloud so perhaps we're on a service where they're not retiring Mercurial?

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
"Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020"

I don't like their decision to delete repos.  Putting them in a read-only mode would have been a lot kinder.

There are tools to migrate to Git (so I guess you keep your history?) but I know from personal experience that building ML has dependencies on having hg installed on your system.  It wasn't hard to remove these.

Long term this is probably good for ML - almost no-one uses Mercurial and needing to learn it must put some people off ML.  Short term it's annoying to migrate!

5
I have an ML build problem in a port in progress.  My simple brain can write 10 line makefiles.  I have added #include vram.h (and bmp.h) to disp_direct.c, and my build gets an error of:

arm-none-eabi-ld: disp_direct.o: in function `disp_set_pixel':
disp_direct.c:(.text+0x158): undefined reference to `bmp_vram_info'

I believe the cause is that the linker isn't trying to link vram.o into disp_direct.o.  How do I add this dependency?  I've tried src/Makefile.src, several variants along the line of:
disp_direct.o: $(PLATFORM_DIR)/vram.o

but no luck.  Anyone got any ideas?  There's a lot of possible makefiles to add things to, and I'm not even sure of the right way of adding this.

6
General Development Discussion / when to use task_create?
« on: July 07, 2019, 06:09:44 PM »
I'm doing some work on logging in my 200D port and I'm confused by the advantages of task_create.  Can someone explain the difference between these two examples?

    msleep(1000);
    do_stuff();

and

    msleep(1000);
    task_create("do_stuff", 0x1e, 0x1000, do_stuff, 0 );   

Is the benefit on the second case related to blocking, because tasks go in a queue?  Is that all there is?

7
I think for 200D that the signature for LoadCalendarFromRTC() has changed. In older cams it looks to take a single argument, a pointer to struct tm. For 200D I see it as taking 5 arguments, with the 5th being the pointer to the struct.

I have two questions: am I right about the sig change? I think LoadCalendarFromRTC() is at 0xe05cd1fe in 200D. A useful comparison point is 0xe00742fc 200D, which == 0xff885058 50D - both call LoadCalendarFromRTC().

Second, and more important; how should I generally handle this problem? Are there existing examples of function signatures differing across camera models that I could copy?
 - I could maybe write a 200D specific wrapper function that takes one arg and supplies the extra ones to the real call.  I believe it's possible to have platform/XXX functions override src/ functions?  I haven't tried this yet.
 - I could use lots of #ifdef CONFIG_200D whenever LoadCalendarFromRTC() is called.  This seems very ugly.
 - I could have an #ifdef CONFIG_200D macro that mangles calls of LoadCalendarFromRTC() to have 5 params and guesses values for the other 4.  I hate this idea.

8
Reverse Engineering / Ghidra scripts
« on: April 07, 2019, 03:17:37 AM »
Ghidra is a free tool similar to IDA Pro.  https://ghidra-sre.org/
You can extend it with scripts, in Java or Python.  I thought we could make some useful ones and collect them here.  I'm going to assume everyone wanting to run scripts has already got Ghidra working and loaded the rom dumps and extra memory regions (eg, parts of the rom that get copied to different locations at runtime).

Here's my first useful script, StubNamer.py - you give it a stubs.S file and it names and disassembles the stubs in your listing:
https://drive.google.com/open?id=17QJSAd-72z_Kp_GgoS6Qn1HdOsQVc832
In Linux, copy to /home/<your_user>/ghidra_scripts/, then it will be visible under Magiclantern when you open "Display Script Manager" (white triangle in green circle icon in button bar).

Limitations:
 - it doesn't define a function at the address, because not all stub addresses are at function starts so I didn't want to force this.  Often Ghidra will work out it's a function due to xrefs etc, but sometimes it doesn't.  Could be made better by inspecting the disassembly, detecting common function starts, only then defining a function?
 - the NSTUB address extraction only handles the simplest case.  If it's a computed address, it will fail (and report this in Ghidra console so you can manually define it)

Pages: [1]