Skip to content

Getting Started

Jump to bottom
vintagepc edited this page Jul 16, 2021 · 24 revisions

Getting started:

If using IPC mode and MK404, build the pipe-frontend branch of MK404. Launch it with the IPCPrinter option. (./MK404 IPCPrinter) It will create a MK404.IPC file in the same directory as the MK404 executable, and wait for QEMU to connect. Symlink this IPC file to the same directory as the QEMU binary (qemu-system-buddy), e.g. ln -s /path/to/MK404.IPC /path/to/qemu/binary/dir/ (Recent versions will use a shared memory queue instead of a named pipe, this symlink step is no longer required.) Then launch the Qemu binary. It will detect the IPC link and use MK404 for simulation display of indicators and motor positions. MK404 can continue running in the background across multiple quits and restarts of QEMU without issue, but if you close it or wish to stop using the IPC functionality, be sure to clean up the invalid symlink, as otherwise QEMU may hang during startup.

Update: IPC has been deprecated in favour of integrating the additional GL windows directly.

Command Line Configurator:

  • I've created a command line configuration tool to help you make sense of the quagmire of options. Just fill in what you want and it'll tell you what arguments you need (which you can then save to a batch file for future use!)

Useful options:

-d guest_errors to print invalid accesses (e.g if you get "couldn't escalate to hard fault" errors) -d unimp to print "unimplemented" logging. Very spammy but might reveal why something doesn't work right if you capture it and narrow down to the part you are interested in.

-S -s Starts the debugging listener for the guest OS and pauses execution so you can use a suitable (ARM) GDB etc (target remote :1234) to debug the running firmware. (use [arm-gdb] [elf file] to load the debug symbols.) If you have VS code with the "native debugging" extension, you can use this launch config with the Buddy firmware repository for debugging Mini firmware:

        {
            "type": "gdb",
            "request": "attach",
            "name": "Remote noboot QEMU",
            "executable": "${workspaceRoot}/build-vscode/firmware",
            "target": ":1234",
            "remote": true,
            "cwd": "${workspaceRoot}", 
            "gdbpath": "${workspaceRoot}/.dependencies/gcc-arm-none-eabi-7.3.1/bin/arm-none-eabi-gdb",
            "autorun": []
        },

Sources are in hw/arm/prusa/ as a self contained folder for easy future migration of qemu versions. `

CTRL+ALT+G will release the keyboard/mouse from the Qemu window. LMB and scroll wheel are the rotary encoder.

**NOTE: ** Do not hit breakpoints in QEMU with the cursor grabbed! You will be unable to release it as keypresses are not processed - and may need to kill your windowing system to regain use of the system.

Enter/keyboard up/down arrows will also move the encoder without grabbing the mouse

Problems?

  • If you do not see any graphical output whatsoever, make sure you have (at minimum) SDL development packages involved. This will net you a plain window as seen above. For a more advanced UI, also install GTK development packages. This will make it more convenient to manage some aspects of the virtual machine and consoles through menus and a tabbed interface.
  • If Mini404 starts, but you only get a black window instead of the mini firmware, double check the -kernel argument. Be sure you are using either the noboot variant, or a .bbf file (with bootloader.bin in the appropriate location)
  • USB support requires libusb, make sure this is detected and enabled by the ./configure step if you intend to use it to connect a drive image.
  • librt is also required for the shared memory queue with MK404. I believe this is a standard development package, but you will get link errors if it is missing.
Clone this wiki locally