5DC boot cache hacks help to fix it

[scrax]

I've tried to restore 5DC to build on vxworks_dm_spy branch and got an almost working build with lot of problems.

After tring to understand the differences from 40D and 450D by reading all topic bout those ports and comparing the code there are some part in 5DC that I cant understand. Alex and Coutts did a great in finding lot of stuff but there are some maybe important stubs not found like current_task.
I tried to find some but with my zero understanding of ARM i can only find a couple.

From what I understood of the boot process 5DC is the only one that is using ARM patches to load ML and maybe those are now partially broken by the changes in ML codebase? In past Coutts first and then 0xAF with help from g3gg0 worked to enable cache-hacks on 5DC but still we don't have it working. I've tried to figure out how to mke it work bu I've just figured out that i've no clue on how to go on, so I'm here for help.

I don't know what is needed to be done to fix the boot process or what can I do like boring easy stuff maybe, I can provide dumps if needed. I'm still making my test without qemu because can't figure out how to make it work with 5DC but didn't tried a lot.

I'm also tring to find current_task and in qemu model_list.c there is a note that curent_task_addr is in MEM(0x2D2C4) is it the same?
And how do I look it out?
Actually my build of ML can't show fonts or save seems, so main output I have is blue and red led. But I can build and load the old port based on the last code from 0xAF and so I think I can use that for getting that MEM maybe

[scrax]

I'm also tring to find current_task and in qemu model_list.c there is a note that curent_task_addr is in MEM(0x2D2C4) is it the same?

I'm reading the topic about M2 port, it have a lot of interesting info but still can't undertand all..

[a1ex]

I'm also tring to find current_task and in qemu model_list.c there is a note that curent_task_addr is in MEM(0x2D2C4) is it the same?

Actually, the MEM was my mistake. In latest model_list.c

Code: [Select]

        .current_task_addr      = 0x2D2C4,

However, the task structure is not the same as DryOS. It looks the same as on other EOS models though. From my notes (to be double-checked):

Code: [Select]

struct task
{
    uint32_t                off_0x00;
    uint32_t                off_0x04;
    uint32_t                taskId;
    uint32_t                off_0x0C;
    uint32_t                off_0x10;
    uint32_t                off_0x14;
    uint32_t                off_0x18;
    uint32_t                off_0x1C;
    uint32_t                off_0x20;
    uint32_t                off_0x24;
    uint32_t                off_0x28;
    uint32_t                off_0x2C;
    uint32_t                off_0x30;
    const char *            name;
    uint32_t                off_0x38;
    uint32_t                off_0x3C;
    /* entry appears to be at 0x74, others unknown */
};

For the old 5D, QEMU should be enough for troubleshooting the early startup process, but it's not going to show the GUI.

I wouldn't recommend testing the early boot code directly on the camera, given that Coutts bricked his old 5D by doing just this.

I can look into it, but... maybe near the end of the week, if you remind me.

[scrax]

I can look into it, but... maybe near the end of the week, if you remind me.

I've added current_task_addr: in qemu and it started once (not the GUI)
But then I've srewed up somehow the qemu install it's now giving me this error:

qga/commands.c:13:10: fatal error: 'glib.h' file not found

Now I have a little problem with hg
I am in the vxworks_dm_spy branch and have all the changes I made to the 5DC uncommited because didn't know how to tell hg that the files relative to 5D are moved from unmaintained and not new.
Now I think I should update to qemu branch and reload the install script to fix my qemu installation and also update it (since I saw you added something for 5DC after I had installed mine)
Maybe I'll save another patch with my changes and then make "hg update -C qemu" install qemu and then go back to vxworks_dm_spy and restore the patch.
But probally there is a more cleaner way with hg commands...
That will not work because the patch file got from "hg diff -g" (like the others I've shared so far) are incomplete since they don't include those 5DC files I've moved out from unmaintained and edited after.

However, the task structure is not the same as DryOS. It looks the same as on other EOS models though. From my notes (to be double-checked):

I don't understand this; you mean that the structure is same as other EOS model with vxWorks and different from the EOS models with DryOs?

[a1ex]

I don't understand this; you mean that the structure is same as other EOS model with vxWorks and different from the EOS models with DryOs?

Right.

I have exactly the same issue with M50, so... let me solve it there first, then I'll look into the old models. Yes, VxWorks cams require pretty similar changes to DIGIC 6/7/8 - it's about updating the codebase to allow such differences in Canon's data structure.

[scrax]

ok seems I've managed to make a full diff now and moved files around ok.
attaching it here