Messages

Fixed the task problem, which was embarrassingly simple in the end.  The OS defines a maximum number of tasks, and this cam happens to be quite close to that limit.  By coincidence, ML tasks were just below that limit before running the benchmarks, and so the second one triggered an assert.

The limit is defined during OS initialisation, and we control that during boot.  I've added an option to increase the task limit, which can be defined per cam:
https://github.com/reticulatedpines/magiclantern_simplified/commit/9df8de520ff38e47386404a10a262062cb7ab09e

Benchmarks look quite promising:
https://i.imgur.com/7bbLlNv.png

Minor but satisfying update: merged changes from Ilia and updated a little - now ML builds with only python3.  No python2 required.

https://github.com/reticulatedpines/magiclantern_simplified/commit/85d0af41615d8c3fdfd5bbfd5cc7cb0f5e2b0260 and some earlier commits.

Digic 7, 8 and X are dual-core parts.  This is distinct from "Dual Digic" - that means a cam with two separate Digic cores, on different "sockets".  Dual-core is two cores on the same die.

We found task_create_ex() a long time ago, that allows one core to create a task that starts on the other.  This task goes into normal task scheduling, which has pre-emption and priorities, so when it runs, or how often, is not strongly controlled by the code creating the task.

Recently I found a method for direct RPC.  A core can send a function address to another core, which will immediately switch to that code, regardless of current task.  In fact, this works before the task system has been initialised, which is valuable.

All addresses are from 200D 1.0.1 unless otherwise stated.  These are fairly easy to find in other cams, there are lots of RPC strings, including to create_named_semaphore().  There's an associated spinlock global that helps, too.

Top-level DryOS function looks like this, 0x34b5a:

Code Select Expand


int _request_RPC(func *param_1, void *func_param)


The first param is a function pointer that takes void * and returns void.  At least on 200D, the param must fit in a single register (no large structs), because a blx r1 happens at one point.

_request_RPC() disables interrupts then calls an inner function that does the work.  The target func address is written into a global - there's a single address for this so there can only be one RPC func in progress at a time.  On Canon side a global spinlock is used to ensure no conflicts.  ML side we use a semaphore.

The caller then wakes up all CPUs and sends an interrupt: send_software_interrupt(0xc, cpu_mask);

During early init, both CPUs have registered a handler for SGI 0xc, 0x349d6:

Code Select Expand


void register_SGI_handler_0xc(void)

{
  register_GIC_handler(0x1cc, check_for_RPC, 0);
  return;
}

The handler looks like this, 0x349ba:

void check_for_RPC(void)
{
  uint cpu_id = get_current_cpu();
  if ((1 << (cpu_id & 0xff) & ~*(uint *)(inter_cpu_spinlock - 4)) == 0) {
    call_RPC_func();
    return;
  }
  return;
}


It looks to me like this is generic code that can cope with up to 8 cores, allowing any core to trigger a function on a masked set of cores (including itself if desired).  Presumably this is library code, and it looks a bit redundant when MAX_CPUS is set to 2.  It seems clear that SGI 0xc is reserved for inter-core comms.

The reason this was relevant to me, is that I've been working on MMU remapping code.  For this, you want each CPU to use the remapped addresses as early as possible - or it will call code that uses the old content, a particular problem if it initialises an external device.  Prior to finding this RPC code, I had no generic way to get cpu1 to see patched memory before it initialised its tasks.  Now, for all the D78X cams I've checked, it's possible to get cpu1 to take patched mem before it starts init1_task...  which means all tasks on both cpus will see our updated memory content.

As a side benefit this means we can intercept init1_task in the same way we do for init_task on cpu0.

Using the DryOS functions directly is a little tricky.  When a cpu wakes up and calls the target RPC function, it's in a loop, and will keep calling it, until the function pointer gets set NULL!  In practice, this means the target function is responsible for clearing the global, or the cpu will loop forever, constantly calling it.  You also must ensure the passed in params remain valid until the RPC call completes - this is easy to forget since the call happens on cpu1; you could easily use local vars for storage, they're on cpu0 stack, and your function ends before cpu1 reads from that stack...

Consequently, in ML code, I wrap this in request_RPC(), that tries to make things safe, in dryos_rpc.c:

Code Select Expand


struct RPC_args
{
    void (*RPC_func)(void *);
    void *RPC_arg; // argument to be passed to above func
};

int request_RPC(struct RPC_args *args)
{
    extern int _request_RPC(void (*f)(void *), void *o);

    // we can only have one request in flight, cpu0 takes sem
    int sem_res = take_semaphore(RPC_sem, 0);
    if (sem_res != 0)
        return -1;

    // storage for RPC params must remain valid until cpu1 completes request,
    // don't trust the caller to do this.
    static struct RPC_args RPC_args = {0};
    RPC_args.RPC_func = args->RPC_func;
    RPC_args.RPC_arg = args->RPC_arg;

    int status = _request_RPC(do_RPC, (void *)&RPC_args);
    return status;
}

void do_RPC(void *args)
{
    extern int clear_RPC_request(void);
    struct RPC_args *a = (struct RPC_args *)args;
    a->RPC_func(a->RPC_arg);
    clear_RPC_request();
    a->RPC_func = 0;
    a->RPC_arg = 0;
    // request complete, cpu1 releases sem
    give_semaphore(RPC_sem);
}


Yeah, if you *actually* want thermal IR, canon sensors won't pick it up.

If you're being contracted to make a ghost and/or UFO cam, just tell them it works and have it fire randomly

I'd say we're at a useful set of definitions now, that's good.  Now you just need to learn how to do it, or convince someone else to do it for you

I haven't used it.  A quick look at the code suggests it only triggers photos.  Looks like it would be easy for someone to adapt for video (leaving aside the question of when to stop the recording).

The existing motion detection would meet that description.  Presumably that doesn't work for you, or you'd use it?

That's why I'm asking for some more detail.  What criteria do you want to trigger on, that simple motion doesn't work?

changes in different infrared frequency light levels - helped by filters

What kind of changes?  Can you describe what your goal is?

Is there a direction in the ML history or development that could help in this?

Too vague a question for me to answer, sorry   Do you mean "help with the thing", or "do the thing"?  Impossible to answer either way without a better description of what the thing is.

Thanks, that's good to learn, and annoying.  Now I'll have to make sure I regularly put a battery in my modern cams - LiON batteries permanently die if they fully discharge.

It's easy to find that Canon has previously used non-rechargeable CR1220 cells a lot for RTC batteries.  Do they use one for the R5?  I don't know.  See if there's a teardown video, you might be able to spot it.  Or crack yours open if you feel like it.

You may well be wasting your time regardless: have you checked if the main battery discharges faster inside a cam compared to outside?  Most rechargeable batteries will lose a lot of charge if you wait a few months.  Personally, I'd still always store cams without batteries in them - it won't lose charge faster, and batteries can (rarely) leak.

From the manual, one of the Creative Filters is "Miniature effect", which "Creates a diorama effect".  Might be that.

LVAf90fps suggests AF refreshes at 90fps, or at least has one mode to do this.  Seems plausible.

Are you trying to fix the connector?  What do you mean by "on the motherboard"?

If you think there's a break in a flex cable, you can use a multimeter to check for continuity on each trace (after you remove the cable from the cam, very carefully!).

If you're thinking of repairing the cable, sometimes it's possible to bridge a break in a track.  If you don't already have some practice at soldering small parts, it's easy to damage the cable further.

Buying a replacement cable might be easier.

[Updates for 2023 Sep - Oct]

Updates for 2023 Sep - Oct
Last commit considered: https://github.com/reticulatedpines/magiclantern_simplified/commit/af2c1123451636fcfd88c0929311b7b4276d386c

There are four pieces of work in this update.  Individually none are large, but all are significant.

First:
I added a developer guide.  This is only the beginnings, but I think it's a good start.  This is a set of Markdown files, and a script to turn them into PDF and HTML forms.  Consequently, you can preview them on Github: https://github.com/reticulatedpines/magiclantern_simplified/blob/dev/developer_guide/03_00_magiclantern.md
The PDF version looks nicest.  See ROADMAP.txt for rather rough plans for the future.  Anyone is welcome to contribute, but it does rather require good knowledge of ML code.

If anyone is interested in working on a User Guide in the same kind of format, I'd be very interesting in getting something into the repo.

There are significant benefits to including the guides in the repo.  It makes it easier to keep them current with the code.  It keeps things together, while the PDF and HTML generation still allows easily using the info in different formats / locations.

Second:
I found direct RPC functionality on dual-digic cams.  This means either core can trigger the other to run arbitrary code.  An interrupt is used to signal the other core.  The latency is very low, and it bypasses the normal scheduling system; as soon as the target core receives the interrupt, it runs the code you specified.  task_create_ex() is likely preferable in most circumstances, but it's useful to have options - and this RPC functionality can be used earlier, before the task system is initialised.  I'll do a longer technical write up as a separate post.

Third:
Improvements to MMU code.  The prior experimental code allowed you to use MMU to patch ROM contents, but required you to find large amounts of unused memory first, which was unreliable and time consuming.  And if you got it wrong, the cam would immediately lock up, requiring a battery pull.  Kitor and I have had several discussions about this, with a few good ideas for possible future work.  I went the route of reserving space within magiclantern.bin for a minimal set of structs to allow MMU remapping one 64kB page.  By using the MMU to intercept init1_task (the root task on cpu1), we can also get cpu1 to take the MMU patches before any tasks are started, in a cross-platform manner (this had been difficult previously due to technical differences in D7 and D8X boot process).

This greatly simplifies using MMU for testing, and entirely removes the possibility of crashes due to memory conflicts.  You can still easily patch things in a dumb way and break things

Because we can't steal much memory in the user mem region occupied by magiclantern.bin, if you want to make several patches in distant regions, this approach won't work.

See 200D for examples on how to configure a cam for MMU, especially CONFIG_MMU_REMAP.

Fourth:
How do we escape the confines of user mem pool?  On D45 cams, we relocate to the Allocate Memory pool.  But this uses cache hack patching, and D678X cams don't have that.  But - D78X do have MMU (Digic 6 will have to wait.  I can see two obvious approaches, both untested so far).

Combining the above, along with some code to automatically assign increasing numbers of the various MMU structs when given more space, I provide a way to locate ML itself, and MMU remap metadata, into Allocate Memory pool.  A few constants need to be chosen / found, but these are easy and portable across cams.  See 200D, PTR_ALLOC_MEM_START, ALLOC_MEM_STOLEN.

This removes prior constraints on ML binary size.  Although I have noticed that the AllocMem pool is quite small on some cams, so it might be better to split ML and MMU between user mem and AllocMem.  No problems observed so far, just worth noting.

Upcoming work
Working with a.sintes to integrate his recent work: 5D3 improved preview, improved card free space display, and a focus sequencing module

It will however mean any loud noise will trigger it.  Might not be practical if you need to leave it unattended for a long period.  And you're going to need a decent sized battery to keep both the phone and the camera on for all that time.

A microcontroller with a decent RTC, attached to the external trigger, will use a lot less power.  But now you need to mess around with microcontrollers, so, depends what your skillset is

I have experience with writing C code. Please, could you point me where it would be the best to start with this codebase?

I think the repo Bilal used for this is here: https://github.com/bilalfakhouri/magiclantern_hg_02/commits/crop_rec_4k_mlv_snd

Altering which recording resolutions are available is not trivial, and requires understanding of how the sensor is read.  You might want to read around forum threads on "FPS Timer", and also ADTG.

This depends on what mode you're shooting in.  E.g. higher res takes more time to read out.

I think one of the ML menus lists the read time per line, can't remember if that's a default or in a module.  Hopefully someone else remembers.  FPS override menu possibly?

Okay, 1.1.2 it is - easier for me too.  I'm currently working on making MMU patching nicer, but hopefully will chat to you Sunday

PS I request pictures of tiny cats.

You've got a large workforce, you just need to get them motivated.  Training the cats to make dinner might be the place to start.

We can update 7D2 version to 1.1.3 if you prefer, I think I picked 1.1.2 because it's the version before they implement downgrade "prevention".  Wouldn't take long to update it, it's a barebones port at present.

I can certainly help with porting work, though I don't recall if I have an easy cable connection for 7D2 uart.  Since it's my work so far, if you have any questions I feel obliged to answer them   You might want to follow the Discord link at the top of the page, it's better for quick questions than the forum (it's like IRC but easier to use).

Yes, I'm trying to help you by answering your questions.

But really, if you want to learn how to work with ML: you have to learn C.

It's hard to understand what you mean.  The code you've listed doesn't make any sense and couldn't run on Canon cams.  You ask about "output all the camera settings in a plain text" - this doesn't make sense and we don't need "camera settings".

I think you're saying something like "why can't we run code that will tell us what we need to know?".  We don't know what questions to ask.  How would we write the code?  AI isn't magic.  It hasn't been trained on these cams, it doesn't know what to do either.

Task creation doesn't use cache hacks, it works fine on Digic 6 (on 750D), 7, 8 and X.  It's just an OS API you can call.  I'm fairly sure I've just made some mistake for 7D2.

You're right that we have no proven way to "edit" ROM code though, and that does impose limitations.  I'm not aware of that affecting task creation.  I believe it should be possible via PMU and an exception handler, but haven't tried to get this working.  MMU patching works on D7 and up, but you like a challenge

I don't recall if anyone has tried rpm based distro before, probably it's fine.  The weirdest requirement is you need python2 and python3 installed (assuming you are working from https://github.com/reticulatedpines/magiclantern_simplified ).

Maybe consider joining discord, most dev chat happens there (and when we have useful results, gets written up on forum).

Hey nice!  I still have mine.  Build quality is high, cam feels good to use, I really like this one.  ML wise it seems to behave better than 5D4 (but these were both fast ports by me, a day or two, not much testing).

The task creation bug that I mention is quite strange.  I wasn't able to create two tasks "at once".  If I create task A, wait for it to exit, create B, all is fine.  If I create A, create B, cam locks up.  I can't imagine they really moved to a serial model for tasks!  So I guess I either have some stub(s) wrong, or they changed the API for task creation (seems unlikely!  Later cams work as expected).

Repo should build easily on Debian (or similar) with arm-gcc tested at versions 8, 9 and 12.

I might be wrong but I assume there is a distinction here between "port Canon code" to get feature X and "implement feature X ourselves".  E.g. Canon "DSLR" line has official raw video now, but presumably nobody thinks we should remove our implementation.  Here it's very clear we didn't take anything from Canon.

Therefore I'd assume it would be fine to implement some log-like raw format, if we could work out a way to do so ourselves.

Yes, almost all ML code is C.  A small amount is ARM asm.  Python is used outside of ML for some tasks.

You don't need to look at FIR files, and this will be a hard task for you, I wouldn't recommend it.  You can dump the ROMs from your camera: https://www.magiclantern.fm/forum/index.php?topic=16534.0

To understand the ROMs I would recommend Ghidra, but it won't show you anything useful until you have more understanding of C (and ideally ARM asm).

Yes, that list of cameras has the same main processor, but the firmware interacts with more than that.  E.g. the AF system is likely different on different cams.  Every camera has a unique firmware, and every camera requires effort to create an ML port.

To create a port for a new cam, you'll need to learn several skills.  How to program in C is one of those, and it's very easy to find guides for learning this.  So that's what I'd recommend first.  It is likely to take you a few months to get to an okay level of experience.  If you get that far, I'll happily give you a list of what to learn next

Re VS Code, I've never used it and don't think any ML dev is using it.  I believe it would be possible to configure it to build an ML repo (it's a standard Unix make build, nothing weird).  It won't help you since there's no support for 800D.  And there are easier ways of building ML.