Notice in photo mode that the simple dng always is set to 470 ISO even if I set frsp to 100 ISO , strange
That sounds about right. Try setting the exposure time in LiveView to 1 second or longer, then compare with the exif info from the simple silent DNG.
Took it from the diff log
The diff log was made with
this code, in particular:
.buffer = 0x12345678,
That was there because:
1) it's not trivial to get a valid address (you'd have to capture an image, this is a bit of hit and miss, depending on camera model)
2) I wanted to see only how the JPEG encoder is configured (the emulation won't go further anyway)
3) 0x12345678 is easily recognizable, so you can see what registers depend on the image buffer
4) it was the simplest way that worked on any camera model
But that 0x12345678 was not meant to be used on real hardware! There you'd have to allocate RAM for both input and output, fill the buffer with valid image data, fill the raw_info structure with correct parameters and so on.
So is the build safe to test?
This particular build is safe, but it will not make any difference (that change is overwritten later, so it's not worth testing it). Generally, with this kind of changes you should be very careful, because in our case, any task (or DMA channel) can write to any part of the memory, and Canon code reflashing things back into the ROM at shutdown is what makes this operation possibly dangerous.
Overwriting memory that you don't know what it does is a risky thing to do.
- if that memory is unused (not read after you have overwritten it), there will be no side effects at all (you may even think it's all OK, when it isn't)
- if that memory (which may contain data or code) is read after you have overwritten it, the side effects can range from:
- temporary (e.g. some parameter changes for a split-second and is set back to the old value at the next iteration
- noticeable (something changes on the screen, prints error, crashes etc)
- insidious (the side effect is visible long after the overwriting, possibly on a totally unrelated feature)
- domino (the code using the modified data gets confused and starts overwriting other stuff)
- extreme (it's not impossible to eventually reach EraseSectorOfROM)
- extremely insidious (modified data gets written into ROM and is noticed days/weeks/months later -
this actually happened!)
In this case, that register was the address of an EDMAC channel (which can read from or write to memory). Luckily, it was a read channel (something that reads from memory), so it's likely safe (not 100% safe - the image processor is a black box - but extremely unlikely to cause issues).
In our particular case:
[0xC0F26908] -> 0x1235FFAA: RAM address ; somewhere in Canon code before our overrides
; our overrides (that big red block on 6D with CLOCK_ENABLE between the lines)
[0xC0F26908] <- 0x12345678: RAM address ; after our overrides, value changed back by SetEDmac
Given that last line, any attempt to override this register has zero effects.
=> it's safe to try this particular build, but you will not notice any difference
=> it's generally not safe to try other builds with similar issues
