Messages

Ah...  here? https://bitbucket.org/Dannephoto/magic-lantern_jip_hop_git/src/master/

Man, that looks like it makes the diffs really confusing.  I guess you're using hg commands locally, then using git commands to store the entire hg state files??  The .hg dir isn't designed to be managed like that, many of the files are binary.  Won't your git repo size bloat really quickly?  It's text oriented, doesn't handle frequent changes to binary files well.  And you have to use both git and mercurial.  Certainly looks painful to me

Mercurial is pretty much dead.  Only a handful of large projects using it, git and mercurial are functionally equivalent and everyone has to learn git, so nobody learns hg.  Using mercurial is a barrier to entry for devs.

I'm incompetent enough with hg that it permanently lost my work multiple times.  That made me angry enough to remove all hg deps and make my repo pure git.  There's an experimental crop_rec branch if you're interested: https://github.com/reticulatedpines/magiclantern_simplified/tree/dev_crop_rec_merge

That branch is not really tested at all.  I don't want any long-lived branches, only one branch for everything.  So, I want to merge it or discard it.  I hear from Bilal that there are some problems with crop_rec on Digic 4 cams, hence why it's not merged yet.

Great, that makes more sense I think (the clone doesn't copy the .hg dir, it creates it).

Not sure what you mean by make needing .hg in some particular place.  Running make in the normal places inside the repo should work and .hg should always be in the repo root, you never need to move it or even think about it.

What do you mean by hg commits to a git repo?  They're not compatible systems.  There are some tools to wrap one in the other, I think?  But that does hurt to some degree; you can't use all the features and now you have two different complex systems as dependencies.

I know very little about hg, it's why I ported the official repo to git.  You shouldn't need ML forums for this, it's a generic mercurial / hg question.

The hg tools create this directory when you initialise a repo.  E.g. via whatever the equivalent of "git clone" is (or "git init", etc).  Presumably you downloaded a zip, rather than make a local repo via hg.

This combines with the ML build system expecting to find both the hg CLI tools, and for the repo to be managed by hg.  You are getting this error because your local files are not hg managed.

You should make your local files a proper hg repo.

Not something I'm familiar with on forums, I don't have any cams that support it.  It's very popular though so I'm sure people can help you out.

The theory is easy: cam has hardware for doing lossless compression for JPEG (LJ92).  ML can send raw data to this, compressing it.  I don't know how it interacts with ISO, although noise characteristics should change how much compression you get.

It's a cool cam, congrats!

The official repo is here: https://foss.heptapod.net/magic-lantern/magic-lantern

No.

Hello, and welcome to Magic Lantern

You are replying to a five year old thread - if you want encryption functionality in the way you've described, you're probably going to have to implement it yourself.  We can help show you how to do that if you'd like.

No, it's not in development and never will be: M5 is not a Magic Lantern target.  It's PowerShot-like and may be supported by CHDK:
https://chdk.setepontos.com/index.php?topic=13014.0

I have a question guys, do you still work on the MK IV, how is it going?

There are no current devs who own a 5D4 and nobody is working on it.  The cause of the current show stopping bug is unknown and hard to diagnose without access to a physical cam.  Once it is resolved progress to the same level as the early 200D port could be fast enough, progress beyond that will be slower.

There will be no progress on 5D4 until we get the combination of dev + cam.

Oh yeah and if you have libvte-X.YY-dev installed at the time you run configure, your qemu serial console will have proper scrollback and a larger screen size.

Try:

Code Select Expand


apt search libgtk|grep dev


It's probably libgtk-3-dev or similar.  You probably want flex and bison too.  Not required for qemu but it prefers it.

It's a fairly clear error (from qemu's configure, nothing special to do with ML).  What happens after you install pkg-config?

Great, I'm glad you got it working.

Ah, I wasn't suggesting you make a VM.  You can use Debian with WSL: https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows/SubsystemForLinux

You changed your environment several times and didn't re-run qemu configure, so it's not picking up those changes (including the addition of bison and flex).  Make clean and then configure again if you want it to use those new things.

If you can't get a rom dump for a few months, that gives you time to learn more C and Ghidra.  The rom dump process is very low risk if you follow the instructions carefully.  Nothing is truly risk free, of course.

Some more understanding of the task scheduler.  I'm now confident that on 200d, e021cc4c is irq_handler(), it runs whenever an irq is triggered, due to VBAR setup in early code, see the table of handlers at e021cb60, associated with VBAR setup at e0040002:

Code Select Expand


coprocessor_moveto(0xf,0,0,&LAB_e021cb60,in_cr12,in_cr0);


See ARM manual, B4.1.156 for that mcr usage.  Also see FUN_e01caa88(&LAB_e021cb60,"Exception vector") for finding VBAR address.

As part of irq_handler(), we have:

Code Select Expand


  if (bVar5) {
    handle_interrupt();
    DAT_0000100c = DAT_0000100c + -1;
    return *puVar6;
  }
  handle_interrupt();
  thunk_FUN_df003028();
  change_running_task_maybe(&PTR_0000101c,&PTR_00001020);


This means that in most cases, handling an IRQ triggers assessing whether the task should change.  Which means the irq_handler is in essence the scheduler.  I assume there's a timer that triggers a periodic irq so it can't stall if the rest of the system is idle

Some of those problems look pretty easy to fix, but only if you have a decent amount of C / gcc experience - I'm guessing you don't?

I'd recommend not using Ubuntu, use Debian Bullseye instead.  That's the distro I use for building and I know it works.

You are probably still building using gcc 11: https://lore.kernel.org/all/[email protected]/

Thanks.  Same file hash here, so that file at least has okay line endings.  I don't see that error.  Qemu fails builds on any compiler warnings, not just errors, so perhaps your compiler produces more warnings than mine.  What does gcc --version show you?  I'm on 10.2.

A quick search suggests you may be using GCC 11 or higher:
https://www.mail-archive.com/[email protected]/msg768454.html

If so the easiest fix will be to downgrade your GCC to 10.

We identified a problem - your files had incorrect line endings.  Then you stopped trying to fix that problem and changed your file contents.  From the logs it looks like you're also running other, unrelated commands, that may change things, too.  Now I can't tell what state your system is in.

Delete all local files for qemu-eos repo and the magiclantern_simplified repo.
Run these commands, and only these commands.  If there are errors, do not run additional commands, instead, report back with the error.

Code Select Expand


git clone https://github.com/reticulatedpines/qemu-eos
cd qemu-eos; git switch qemu-eos-v4.2.1; cd ..
mkdir qemu-eos-build
cd qemu-eos-build
../qemu-eos/configure --target-list=arm-softmmu --enable-plugins --disable-docs --enable-vnc --enable-gtk
make -j16


I expect that will fail because you have incorrect line endings.  If it does fail to build, determine the last source file that had a problem and get the sha1sum hash of it and report that here.

It's progress - you identified the problem of bad line endings, but the fix was inappropriate.  Using dos2unix is not a great solution because it won't fix things for the future, and it edits files which will lead to changes that git will see and try to track or, worse, commit upstream.  What you need to do is determine *why* you had bad line endings, and fix that problem.  What other problems might happen due to that unfixed cause?

^M is a Windows carriage-return character.  When you are using git, are you working in Windows, or in WSL?  You might have bad git config, set to change line endings, or you might be using some Windows tool that is changing them.  Find out what caused it, *remove* your local qemu-eos repo, and re-create it.  That will fix all line endings. 

This is your error:

Code Select Expand


/bin/sh: 1: ./scripts/git-submodule.sh: not found


What happens if you are in qemu-eos-build and manually run:

Code Select Expand


./scripts/git-submodule.sh


Also please show the result of this command:

Code Select Expand


ls -l ./scripts/git-submodule.h


I'm guessing the file isn't executable.  If it isn't executable, you probably have bad config for either git or umask, on a Linux system these files should be created executable.

I think if you do this that it won't work on older cams:

Code Select Expand


case 2:
            W = 640;


Very old cams I think don't have that high a resolution, 320x240 maybe?

You have docutils-common, but are you on Debian, and do you have rst2html?  What is the output from this command?

Code Select Expand


rst2html --version


The reticulatedpines repo is mine.  I modernised several things in the code to make it easier to build on modern linux.  Your log for 200D shows you're using gcc 5, which is very old.  I suspect the error is related to this.  I guess you're using a very old Linux.  I use Debian Bullseye and install gcc like this:

Code Select Expand


apt install gcc-arm-none-eabi

That gets me arm-none-eabi-gcc version 8.3.1, which builds fine.  Try again with a similar version of gcc.

Thanks for the bug report, it was well written.  I've closed it, because I don't want to maintain anything to do with qemu 2.  I've explained further in the ticket.