Canon 100D / SL1

[IDA_ML]

I have just tested the latest experimental lua_fixing build for the 100D:

magiclantern-lua_fix.2017Sep11.100D101

MLV Sound is still not working.  Exactly the same behaviour as described in my post 664 under "NOTE:" is observed.  Camera needs to be turned OFF and then ON again after each clip to have MLV sound.

I did not get an answer to my question:
------------------------------------------

Is it technically possible to fix the MLV-sound issue on the 100D that requires turning camera off and on again with the mechanical switch after each clip?

[IDA_ML]

I don't know how many owners of the 100D noticed but this little beast is in the Nightlies already!!!  Congratulations and many thanks to the developers for their enormous efforts!

I have just checked the sound recording function with 14-bit MLV recording and it performs as follows:

1) 1-st recording after camera has been turned ON is normal - 109 frames at the 1728x972 resolution and FPS override turned off.  The .WAV file (about 823 kB) is there after MLVFS conversion and plays fine;

2) 2-nd recording ends with the red message on the screen saying: "Audio failed to stop.  State 4".  The .WAV file is still there and is about 815 kB but it remains silent.  When I try to play it, the progress bar shows the right duration but no sound is heard.

3) 3-rd recording behaves as the 2-nd.  No sound comes out.

4) 4-th recording starts with the message "Threads failed to start"and camera freezes.  It needs a battery pull out, restart, and modules loading to continue working. 

We seem to be very close to sound recording with RAW video on the 100D.  Hopefully, the above information will help to resolve the issue.

[Nex]

Does nightly boot for you? For me only running version is the one from Jul 12.

I have tried disabling, reinstalling, and newer builds simply dont boot the camera. O_o

[JohanJ]

Does nightly boot for you? For me only running version is the one from Jul 12.

I have tried disabling, reinstalling, and newer builds simply dont boot the camera. O_o

Strange thing. Works like a charm here, both nightly 2017-09-15 and lua_fix 2017-09-11.

Sent from my SM-T719 using Tapatalk

[a1ex]

If it fails for you, but works for others, one option for troubleshooting would be to install QEMU and run it directly from the SD card (so we can see why it doesn't boot). I can guide you for that - what operating system are you using?

The safest way (but requires some disk space) would be to create an image of your SD card (dd if=/dev/your-sd-card of=sd.img bs=1M) (on my system, it's /dev/mmcblk0) and run QEMU from the resulting sd.img. For a quick test, if you know what you are doing, replace "file=sd.img" with "file=/dev/your-sd-card", but be very careful not to give the emulated firmware access to your hard-disks! (risk of data loss).

[Nex]

Yea, it is strange - I am on Linux, and I have qemu installed - would need to know how to run our camera on it though.

Ps. I know that nightlies used to work for me, but now its dead silence.

[a1ex]

I assume clicking the above QEMU link didn't work for you, so...

https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/

[Nex]

I was before my morning coffee. Will check it out today's evening! Cheers man.

Should I use 100D branch? Or trunk?

[a1ex]

I'd say test the nightly binaries directly - the differences from our environment would be (1) your ROM and (2) your SD card contents.

To install QEMU, use the "qemu" branch (follow the README).

edit: just added the above notes to the README:

https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/#rst-header-running-from-the-physical-sd-cf-card

The following debug options may be helpful: "-d debugmsg" or "-d io" (or both).

[OlRivrRat]

   SL1 working Fine here running 15sep17 Nightly ~ Have not had Need or Chance

to use M'L' yet but All Seems fine (Looks Normal) in the Menus ~

                     ORR ~ DeanB

[Nex]

I'd say test the nightly binaries directly - the differences from our environment would be (1) your ROM and (2) your SD card contents.

To install QEMU, use the "qemu" branch (follow the README).

edit: just added the above notes to the README:

https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/#rst-header-running-from-the-physical-sd-cf-card

The following debug options may be helpful: "-d debugmsg" or "-d io" (or both).

Ok - so when you know how to do it - its easy.

Went further than nothing - managed to see the camera screen + build info and crash with:
"Error loading: ML/MODULES/100D_101.sym": File too large...

Just before that - happens (for a split second, so I didnt notice at first):
ASSERT: FALSE
at EstimatedSize.c

Ps. Looking for the log file... O_o

Ps2. This message is not the right one.. As file is same as in Jul version that works.. I cant grab log - as qemu doesnt access .img file..

Ps3. Tested with my rom-dump + sd.img from my card.

[a1ex]

As file is same as in Jul version that works..

That might be the issue - you need to replace both autoexec.bin and the symbols file, as they are tightly coupled.

Embedding the symbols file into autoexec.bin would avoid this, but a few camera models have issues with static memory allocation (autoexec.bin size), so we'd have to move more stuff to modules before doing that.

[nikfreak]

I have tried disabling, reinstalling, and newer builds simply dont boot the camera. O_o

No clue what's going on for you Nex as all works fine here. Did you try any other sdcard or even from scratch yet?
(format in cam, download latest experimental build [extract & replace, run fir installer]

Code: [Select]

"Error loading: ML/MODULES/100D_101.sym": File too large...What's the file size?

[Nex]

No clue what's going on for you Nex as all works fine here. Did you try any other sdcard or even from scratch yet?
(format in cam, download latest experimental build [extract & replace, run fir installer]

Code: [Select]

"Error loading: ML/MODULES/100D_101.sym": File too large...What's the file size?

Actually it's the same file as in Jul. Both files, even one from Sep, have even same modify date for me.

I did clean install from both Jul and Sep on two memory cards. Jul boots, Sep doesn't even bring light in camera. In qemu it at least goes to first screens.

[a1ex]

That's weird - the first thing ML does, after checking autoexec.bin checksum (to prevent running code from a corrupted file), is turning on the SD card LED. On most recent models, Canon bootloader also does that when loading autoexec.bin (that's before our code gets executed). Make sure you take the battery out after each failed startup attempt (as the power switch is just a soft button).

Are you able to compile ML and run "hg bisect" to find out when the issue appeared?

[Felipe]

SL1 Working Great, like a factory firmware, I haven't buy the 80D Until we can see ML for that model.

[IDA_ML]

Did you test the MLV-sound function, Felipe?  Does it work without the need to turn OFF and ON the mechanical switch after each clip or does it work as described in my post 676?

[Felipe]

I'm sorry don't use MLV, rather .MOV High bit rate, and no problem.

[Nex]

That's weird - the first thing ML does, after checking autoexec.bin checksum (to prevent running code from a corrupted file), is turning on the SD card LED. On most recent models, Canon bootloader also does that when loading autoexec.bin (that's before our code gets executed). Make sure you take the battery out after each failed startup attempt (as the power switch is just a soft button).

Are you able to compile ML and run "hg bisect" to find out when the issue appeared?

Then if I don't get the light, it means files are corrupted? And why does emulator on my Rom go further... This is really. Intriguing.

[a1ex]

I doubt the files are corrupted.

If you can compile ML, you could start debugging in reboot.c, then in boot-hack.c, by placing LED blinks at various stages to check whether the code reaches them. That's also helpful for finding out where it locks up.

[Danne]

Regarding sound issue. It´s more or like this what is happening:
https://bitbucket.org/hudson/magic-lantern/pull-requests/646/added-sounddevshutdownin/diff#comment-None

Is this line in stubs.S working for the eos100D?

Code: [Select]

NSTUB(0xFF115108,  SoundDevShutDownIn)
Just got my hands on this little beast. Like a beefy version of eosm 

[nikfreak]

For FW1.0.0 I changed the stub soem time after your linked PR got merged w/o detailed testing. Previously we were using the same adress like StopASIFDMAADC (6D / 70D / ... does that too):

https://bitbucket.org/nikfreak/magic-lantern/commits/177b16a9f300f510d317257bcc5c5c17e1c70e23?at=100D-new

Can you change to below and try (if you have time) so it matches StopASIFDMAADC:

Code: [Select]

NSTUB(0xFF1123D4,  SoundDevShutDownIn)
Guess it could make IDA_ML happy.

[Danne]

Code: [Select]

NSTUB(0xFF1123D4,  SoundDevShutDownIn)Unfortunately not working.

Got word from dfort and tweaked a bit. This works:


How about add both in mlv_snd.c:

Code: [Select]

extern WEAK_FUNC(ret_0) int SoundDevShutDownIn();
extern WEAK_FUNC(ret_0) int StopASIFDMAADC();

Code: [Select]

    /* some models may need this */
    SoundDevShutDownIn();
    StopASIFDMAADC();
    audio_configure(1);

[Nex]

I doubt the files are corrupted.

If you can compile ML, you could start debugging in reboot.c, then in boot-hack.c, by placing LED blinks at various stages to check whether the code reaches them. That's also helpful for finding out where it locks up.

Will try on the weekend - or will pray that next nightly magically works (which is a silver bullet in many cases...).

[nikfreak]

Danne my suggestion for the stub address change (match StopASIFDMAADC) equals your screenshot. So if that (screenshot) works my suggestion should also work. will try out myself some time l8er.

update: sorry my fault. it should be:

Code: [Select]

NSTUB(0xFF112680,  SoundDevShutDownIn)