Display (bitmap overlay)

srsa_4c

philmoz
Seeing the same on the G7X2 and G5X - not sure what is going on here.
The rightmost 3rd of the CHDK bitmap image seems to get shifted left to the centre.
@srsa_4c - any thoughts?

I'm still saying that the "scaling bits" we're using are actually something else.

I dumped the ximr struct while recording and found it to be different from idle mode by a bit (literally). The 4th halfword in ximr_context (unk2[0] in case of g5x) is normally 0x500 but becomes 0x100 during recording. I tried modifying it to be always 0x500 and that seemingly worked (I see nothing wrong, but who knows).

philmoz

srsa_4c
I dumped the ximr struct while recording and found it to be different from idle mode by a bit (literally). The 4th halfword in ximr_context (unk2[0] in case of g5x) is normally 0x500 but becomes 0x100 during recording. I tried modifying it to be always 0x500 and that seemingly worked (I see nothing wrong, but who knows).

Thanks - that works for the G5X and G7X2; but it makes me a little uneasy.

If we had 2MB of free memory for all cameras we could use a full res buffer (960x540x4).
This will also slow down drawing and erasing though.

reyalp

FWIW, I noticed on g7x that using analog video out (or force_analog_av) completely breaks both the Canon and CHDK UI. Example screenshot from video capture, with CHDK menu open. I haven't looked further and don't think this is an urgent issue, just noting it as a data point.

In normal video out, the Canon UI dimensions change compared to the LCD, to move the UI elements away from the edges of the screen. The overall viewport buffer dimensions are unchanged, at 720x480

philmoz

reyalp
FWIW, I noticed on g7x that using analog video out (or force_analog_av) completely breaks both the Canon and CHDK UI. Example screenshot from video capture, with CHDK menu open.

srsa_4c noted that earlier with HDMI output at less than full HD res.
Unfortunately I don't have any way to replicate either case.

CanonUser9000

Can you check the zebra color settings for over and under exposure (CHDK Settings -> Color Settings).
Make sure they are valid colours and not transparent.

Tested several color combinations w/o any influence.

Also, the thresholds may need to be adjusted. Some (mostly earlier digic 6) cams use values in the 16-235 ish rather than 0-255, so to see anything in zebra the thresholds need to be large.

:😀 Thats it! Noticable zebra is displayed if thresholds for underexp>=19 and overexp>=21

reyalp

I added debug_logging_ptr, debug_logging_flag and mzrm_sendmsg_ret_adr to finsig_thumb2. I intentionally did this in the trunk sig finder and merged the changes to the ximr tree. May regret this later, but I think if we keep the actual stubs updates in a separate commit, it should work out ok.

edit:
and FW_YUV_LAYER_BUF as a DEF_CONST

CanonUser9000
:😀 Thats it! Noticable zebra is displayed if thresholds for underexp>=19 and overexp>=21

It seems like we will probably want a camera.h define / camera_info field to define which variant is used (if it's truly camera specific rather than settings or output device, as it seems to be so far). That would at least allow reasonable defaults for the zebra and histogram limits.

reyalp

I added support for sx710hs and sx730hs.

With the sig finder additions, the main things that need to be manually verified are the register and message IDs in debug_logging_my, and any viewport dimension logic in update_ui

philmoz

reyalp
I added support for sx710hs and sx730hs.

With the sig finder additions, the main things that need to be manually verified are the register and message IDs in debug_logging_my, and any viewport dimension logic in update_ui

Thanks for that. Nice work on the sigfinder additions 😀

I've added these to the Google Drive link if anyone wants to test them.

pigeonhill

@philmoz

Just spotted and confirmed a strangeness with the G5X EVF.

As I only use M mode I had not spotted it before, plus this is the only non-M3 camera I have with a built in EVF.

In all modes, other than C, the EVF looks fine.

If CHDK is not on the card, or no card in the Cam, C mode is OK in the EVF.

With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.

BTW I'm using the latest build from your repository and the corruption was there before, ie I tested a previous build. Thus likely there all the time, but not spotted as I don't use C mode.

Cheers

Garry

c_joerg

Which Mode (AV, P, M...) is saved on C?

pigeonhill

M

Update

Just tried resetting several times and problem has gone away. 😀

srsa_4c

pigeonhill
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.

Since this new drawing method isn't finalized yet, we'd really like to know more about these cases where it fails.

Just tried resetting several times and problem has gone away.

A missed opportunity, sadly.

What I'm thinking is: we could make copies of the ximr struct (one for normal, one for the yuv case), and write them to card when the debug shortcut is pressed. We could use the memory dumper mode (DmpRAM), but write our debug buffer instead.

pigeonhill

@srsa_4c

A missed opportunity, sadly.

The problem was definitely there, ie only when CHDK was enabled on the card and I was in Manual C mode.

I then reset C mode to Av and then back to M mode and the problem disappeared.

I’ll keep looking out for ‘anomalies’ and report.

Cheers

Garry

philmoz

pigeonhill
With CHDK on the card, and enabled, ie locked, and in C mode, the LCD is OK, but the EVF is completely corrupted, ie 100% full of rubbish pink green dots in three horizontal bands.

@pigeonhill

I don't see any issues with the EVF on my G5X even in C mode - so there may be some Canon setting that is affecting the EVF that I am not using.
Can you list what settings you have saved to your C mode.

Also what firmware version is your camera.

philmoz

pigeonhill
Just tried resetting several times and problem has gone away. 😀

@pigeonhill

Did you reset the Canon settings or the CHDK settings?

pigeonhill

Did you reset the Canon settings or the CHDK settings?

I just changed the Canon custom setting, ie from M to Av and then back to M.

srsa_4c

I've been doing some research on the Zico side, some of this may help clear up a few of the unknowns. I did not try any of the following on camera.
- There is an optional (output?) MARV struct, starting at byte offset 12 of ximr_context. At least two fields in the struct need to be nonzero for it to be recognized. I don't go in details as I doubt this is of any use.
- The halfword at byte offset 6 of ximr_context seems to be referred to as "DivSize". It gets compared with width1 (at byte offset 2). width1 and height1 seem to be the maximum width and height used in layers. When width1 is set to 0xffff, the layers are searched for the largest width.
- There is a color type 3 (probably not used) which needs some additional bytes of ximr_context filled (so it would be quite difficult for us to try).
- The first 18 bytes of ximr_layer are written to MMIO like this (I did this by hand, mistakes are possible):

*(uint32_t*)0xc80b0040=u8_14 | (u8_13<<2) | (u8_12<<6) | (u8_11<<😎 | (u8_10<<10) | (u8_9<<12) | (u8_8<<14) | (u8_7<<16) | (u8_6<<1😎 | (u8_5<<20) | (u8_4<<22) | (u8_3<<24) | (u8_2<<26) | (u8_1<<2😎 | (u8_0<<30)
*(uint32_t*)0xc80b0044=u8_17 | (u8_16<<😎 | (u8_15<<16)

The bits are not masked before the OR operations, which explains why I found scale bits somewhere else. The 18 bytes are followed by 6 halfwords (which don't overlap like the first bytes can).

One more finding: there is an additional memory range that the Zico core sees: 0xBFF1xxxx. It contains a few kB of interface functions that write to MMIO. I had to memcpy it out using Zico side code as that range is inaccessible from ARM. Strangely, I can't find that code in the ROM dump(s) and I also couldn't find a piece of code that would fill it. So, it's either stored compressed/scrambled, or it's on-chip ROM.

Ant

@srsa_4c
Have you managed to activate zico's debug logging functions?
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a). But I assume that it uses UART for output. Maby there is a way to redirect it's output to zico log in RAM?

srsa_4c

Ant
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a). But I assume that it uses UART for output. Maby there is a way to redirect it's output to zico log in RAM?

The optional debug info is always printed through function pointers. You'd need to set the pointer to an appropriate function. For that you'd need to make a wrapper to a known printf-like function (so that the source arguments are processed correctly).
The problem is, I don't see how to access arguments passed on stack. I would expect that the function would get them starting at the offset specified in the entry instruction (so, in case of [tt]entry a1, 32[/tt] the first stack param would be at [tt]a1 + 32[/tt]). *~~But that does not seem to be the case. Do you happen to know an easy-to-understand tutorial that explains this?~~

edit:
*I found a function that does that, will try to make a wrapper to see if it works.

srsa_4c

srsa_4cwill try to make a wrapper to see if it works.

First try, it does not crash, but I can't see if it works. Handles up to 10 arguments, in theory.

# xtensa-elf-as try1.s -o try1.o
# xtensa-elf-objcopy -O binary try1.o try1.bin
# to check generated code: xtensa-elf-objdump -d try1.o

.text

.begin

.align  4

j       myhack

.align  4

.literal_position

_logprintf:
.word   0xBFF23434
lpf_arg1:
.word   0xBFF04358
lpf_arg0:
.word   9

myhack:

entry   a1, 64
l32r    a8, _logprintf
l32r    a10, lpf_arg0
l32r    a11, lpf_arg1
mov     a12, a2
mov     a13, a3
mov     a14, a4
mov     a15, a5
s32i    a6, a1, 0
s32i    a7, a1, 4
l32i    a2, a1, 64
s32i    a2, a1, 8
l32i    a2, a1, 68
s32i    a2, a1, 12
l32i    a2, a1, 72
s32i    a2, a1, 16
l32i    a2, a1, 76
s32i    a2, a1, 20
callx8  a8
mov     a2, a10
retw
.end

Binary:

unsigned char rawData[68] = {
	0x06, 0x03, 0x00, 0x00, 0x34, 0x34, 0xF2, 0xBF, 0x58, 0x43, 0xF0, 0xBF,
	0x09, 0x00, 0x00, 0x00, 0x36, 0x81, 0x00, 0x81, 0xFC, 0xFF, 0xA1, 0xFD,
	0xFF, 0xB1, 0xFB, 0xFF, 0xCD, 0x02, 0xDD, 0x03, 0xED, 0x04, 0xFD, 0x05,
	0x69, 0x01, 0x79, 0x11, 0x22, 0x21, 0x10, 0x29, 0x21, 0x22, 0x21, 0x11,
	0x29, 0x31, 0x22, 0x21, 0x12, 0x29, 0x41, 0x22, 0x21, 0x13, 0x22, 0x61,
	0x05, 0xE0, 0x08, 0x00, 0x2D, 0x0A, 0x1D, 0xF0
};

It's portable, 3 words from offset 4 need to be adjusted as they are model/fw specific.
Loader:

zico_mem=0xbff27940 -- free space in zico code memory
zico_dbg_ptr=0x40c13540 -- 0xc13540 in xtensa
call_event_proc("System.Create")
buf=call_event_proc("AllocateMemory",1024)
imgfile=call_event_proc("Fopen_Fut","A/demo.bin","rb")
call_event_proc("Fread_Fut",buf,128,1,imgfile)
call_event_proc("Fclose_Fut",imgfile)
call_event_proc("memcpy",zico_mem,buf,12😎
call_event_proc("FreeMemory",buf)
poke(zico_dbg_ptr,zico_mem) -- this might crash zico in case of caching issues

Addresses are for m10 101d, so need to be adjusted.

« Previous Page Next Page »