It very much depends on what you are trying to do.
The code sequences suggested in reply #397 should be quite safe. Logging code was already tested on 5D4 (an earlier version, not the latest codebase), so it should be OK, too. Other code sequences (e.g. found in 80D thread) should be OK
as long as they don't use hardcoded pointers. If in doubt, ask.
In particular, stay away from EraseSectorOfRom and similar (I'm pretty sure you will), don't attempt to change properties yet (the proof of concept code doesn't include any backend for that) and try not to overwrite Canon's data structures (double-check any pointers you use for writing). Canon firmware saves some of their settings at shutdown
by reflashing the main ROM, so you'll want to be extra careful not to overwrite their data structures.
If something goes really wrong, you have the boot flag enabled, so you will still be able to run diagnostic code on the camera (unless you somehow manage to erase the bootloader... extremely unlikely). From there, I can inspect the (non-booting) ROM, debug it in QEMU, reflash it with a good copy and so on. I did that on some other models (recently on 5D3 and 70D), but... let's hope we'll never get there. Worst case:
JTAG and
UART (I've never tried these on physical hardware).
A while ago I wrote
a short guide on safety, that I should update.
On 80D, I have used some hardcoded pointers (such as 0x30000000, 0x28000000 and so on). Do not use them; they are not valid on any other camera. Rather, follow the source code comments and run the test code to find out what memory areas appear to be free
on your camera, and use those instead. In any case, these pointers are well above DryOS and general-purpose memory buffers; these are managed by
RscMgr and used for things like image capture, processing, LiveView and others. I highly doubt writing into these by mistake could result in permanent camera damage, but I still prefer to triple-check before using them.
Writing into the display buffer is safe (and hopefully that's all you need for a Hello World), but first you need to know its address. It's not going to be the same as on 80D (or other models). This can be found either from a RAM dump (there are tutorials around the 'net), or from diagnostic logs. The MMIO registers are also different, so what worked on 80D is going to require some (hopefully minor) changes.
To summarize, the next steps are:
- try the code sequences from reply #397 [easy]
- get a RAM dump and identify the image buffers [easy]
- you can attempt to print things on the screen at this stage, but I prefer to know what I'm doing, so...
- run
this experiment to find possibly unused memory areas (this was linked in reply #408)
- update log-d6.c and io_trace.c with the hardcoded memory buffers found at previous step
- enable LOG_EARLY_STARTUP in log-d6.h
- also enable io_trace (see 80D Makefile)
- this will give you a fairly complete startup log (debug messages + interrupts + MPU messages + MMIO activity)
- from this log, we will be able to see how the display buffer is configured (for Hello World) and many other details that will be useful later.
- Hello World!
- afterwards, getting an initial ML port (with basic functionality) should be relatively straightforward.
