How to run Magic Lantern into QEMU?!...

[heder]

The key are correct when running with local display/keyboard on my Ubuntu server, but when running via vnc the
keys are incorrect.  So the problem is not qemu/linux but properly tightvnc/windows.  Not that big a issue,
I'll just remap the key to something useable.

5-8-2019
Was using vncserver, changed to x11vnc on display :0, problem gone 

[felix_]

Is the tutorial out of date? I dont get the qemu-2.5.0 folder and the eos-qemu folder and the configure.sh script
here is a tree of my install folder https://pastebin.com/eTtkg5s1 The last command I ran successfully was ./install.sh  Where do I get the missing files and folders?

[felix_]

Never mind, I solved it

[timbytheriver]

First attempt at installing QEMU in my local environment.

Install itself seems to be ok, but get error screen when attempting to run:

/path/to/qemu-eos$  ./run_canon_fw.sh 5D3,firmware="boot=1"




Why the message about 1.2.3? The code I copied to the sd.img was 1.1.3 So…

1) I mounted my camera SD card (with my current build on it) and copied the files to the sd.img as usual. Is this correct?

2) "For models that use a serial flash, you may have to dump its contents using the sf_dump module, then copy SFDATA.BIN as well." Should I be doing this for 5D3?

All I have in my QEMU/5D3 folder is:

debugmsg.gdb
ROM0.BIN
ROM1.BIN

Thanks.

[timbytheriver]

*UPDATE*

Decided to start over again. Deleted qemu-eos folder.

Followed these excellent video tuts: https://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686 and https://www.magiclantern.fm/forum/index.php?topic=2864.msg190851#msg190851

Installed with no error messages.

Partial success: I can now get to the qemu canon screen. But the keystrokes do not control navigation. I can see that the keystrokes are received at the terminal – but no menu navigation happens. I read an @a1ex post which suggested adding the Terminal to Security panel. This allowed me to control the menus with the arrow keys one time – but subsequently froze, and hasn't worked again.

Ideally I'd like to be able run qemu from a custom image of my physical SD card– but am having trouble making this work also.

Any suggestions?

I have read the thread, the README and searched.
Mac OSX Mojave 10.14.6

[SubZeroz]

Hi,

BitBucket is not working anymore...
Is there anywhere else I can get the script to patch QEMU?

Thanks!

[names_are_hard]

Please tell us which patch you are referring to.

[yourboylloyd]

Hi,

BitBucket is not working anymore...
Is there anywhere else I can get the script to patch QEMU?

Thanks!

You have to do some manual link editing. The QEMU migration solution is here and the first post of that thread is the original tutorial:

https://www.magiclantern.fm/forum/index.php?topic=991.msg230220#msg230220

[Ant123]

Some progress with GUI emulation on EOS M3:




Is it possible to utilize more than one host's core by QEMU?
For example for display redrawing.
My current implementation converts zico's rgba buffer to yuv bitmap+opacity, then converts yuv image and yuv bitmap buffers to rgb, mix them using opacity buffer and put the result to QEMU's output buffer. This is a job for the second core.

[names_are_hard]

Cool!  Which Qemu are you using?

The steps you describe sound sequential to me, which is often not improved by running in parallel.  Qemu does support parallelisation, but I've never used it myself.

[Ant123]

qemu-2.5.0
These steps are performed on special hardware(zico and display controller) independently of the main (ARM) core. So they could be emulated by the second thread independently...

[kitor]

My current implementation converts zico's rgba buffer to yuv bitmap+opacity, then converts yuv image and yuv bitmap buffers to rgb, mix them using opacity buffer and put the result to QEMU's output buffer. This is a job for the second core.

Static source and destination addresses or you somehow parsed XimrContext?
Good to see a progress on that.

[Ant123]

Static source and destination addresses or you somehow parsed XimrContext?

The second one. ATM I use only one RGBA buffer. It's should be enough for playback mode

Good to see a progress on that.

It is bad that A1ex and other 'guru' developers  show little activity now. There are less than 20 commits for two years. 

[kitor]

The second one.

Good and bad at the same time.
Bad - considering XimrContext struct changed multiple times in Digic6 gen and then for each next generation. It will require work for multiple models.

Good - I noticed this week that GUI code on R swaps buffer addresses inside VRAM struct used for 1st layer (GUI) somewhere on early boot. If I grab GUI VRAM struct fast enough, I get pBitmap address of overlays buffer instead of GUI. Thus hardcoded addresses would fail quickly.

@coon messed around eeprom code (d7/8 EOS won't boot due to that), but I'm not sure if he implemented it eventually.

[Ant123]

Good and bad at the same time.
Bad - considering XimrContext struct changed multiple times in Digic6 gen and then for each next generation. It will require work for multiple models.

It's not a big problem. Look at CHDK: they support 160 cameras and 320+ firmwares.

Good - I noticed this week that GUI code on R swaps buffer addresses inside VRAM struct used for 1st layer (GUI) somewhere on early boot. If I grab GUI VRAM struct fast enough, I get pBitmap address of overlays buffer instead of GUI. Thus hardcoded addresses would fail quickly.

The current YUV Bitmap address can be obtained from MMIO register of display controller.

[names_are_hard]

It is bad that A1ex and other 'guru' developers  show little activity now. There are less than 20 commits for two years. 

Yes, this is not ideal.  But I have a fork that is reasonably active: https://github.com/reticulatedpines/magiclantern_simplified/commits/dev

The primary purpose of my repo is to try and get Digic 6, 7, 8 cams supported.  We are making good progress and have menus etc working.

That repo has Qemu 4.2.1, and is a merge of lua_fix, unified, qemu and digic6-dumper, so for most things you can work on it directly rather than needing to keep swapping branches.  I've updated the build system a little so it works with more modern Linux tools, it works with Debian Testing for me.  Qemu 4 is not fully tested and not perfectly equivalent to 2, but it's pretty good - can boot e.g. 50D to full GUI including ML GUI.  Qemu 4 is slightly out of date now.  It was supported when I ported ML patchset, but isn't anymore, so it wants updating to 5.

I'd be interested in seeing your changes and happy to consider PRs etc!

[kitor]

The current YUV Bitmap address can be obtained from MMIO register of display controller.

I was writing about RGBA 'input layer', not YUV 'output chunk'. EOS firmware have a nice pointer from WINSYS that points to VRAM struct that happens to be 1st layer in XimrContext. In EOS R, inside that VRAM struct, pointer to buffer changes somewhere during early boot.

That's why I said it is good, as if you parse XimrContext - it doesn't matter

[names_are_hard]

With Ant's help I have duplicated this - can run M3 to GUI locally.  Thank you Ant for being patient with my stupid questions!

I have a lot of qemu tasks that I can work on.  Largely these need C and linux make skills, not ARM asm or ML experience.  So if anyone would like to volunteer, these are more accessible tasks.
 - get local qemu-eos test suite for ML working in 2 and 4, so they can be compared
 - as needed, improve tests or qemu-eos 4 accuracy, so that 4 is at parity with 2 for ML tests
 - update qemu-eos from 4 to 5: 4 is no longer supported (6 is very new, I think 5 is a better target)
 - using M3 as a guide, extend support to other modern cams (this will need ML and asm knowledge!)