Display (bitmap overlay)

pigeonhill

1155

Re: Display (bitmap overlay)

« Reply #330 on: 10 / June / 2021, 13:12:57 »

Advertisements

M

Update

Just tried resetting several times and problem has gone away.

« Last Edit: 10 / June / 2021, 14:44:41 by pigeonhill »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #331 on: 10 / June / 2021, 17:22:55 »

Quote from: pigeonhill on 10 / June / 2021, 11:36:24

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.

Quote

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.

Logged

pigeonhill

1155

Re: Display (bitmap overlay)

« Reply #332 on: 10 / June / 2021, 17:34:17 »

@srsa_4c

Quote

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

Logged

philmoz

3450

Re: Display (bitmap overlay)

« Reply #333 on: 10 / June / 2021, 17:57:31 »

Quote from: pigeonhill on 10 / June / 2021, 11:36:24

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.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

philmoz

3450

Re: Display (bitmap overlay)

« Reply #334 on: 10 / June / 2021, 18:01:41 »

Quote from: pigeonhill on 10 / June / 2021, 13:12:57

Just tried resetting several times and problem has gone away.

@pigeonhill

Did you reset the Canon settings or the CHDK settings?

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

pigeonhill

1155

Re: Display (bitmap overlay)

« Reply #335 on: 11 / June / 2021, 00:33:03 »

Quote

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.

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #336 on: 12 / June / 2021, 17:37:04 »

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):

Code: [Select]

*(uint32_t*)0xc80b0040=u8_14 | (u8_13<<2) | (u8_12<<6) | (u8_11<<8) | (u8_10<<10) | (u8_9<<12) | (u8_8<<14) | (u8_7<<16) | (u8_6<<18) | (u8_5<<20) | (u8_4<<22) | (u8_3<<24) | (u8_2<<26) | (u8_1<<28) | (u8_0<<30)
*(uint32_t*)0xc80b0044=u8_17 | (u8_16<<8) | (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.

« Last Edit: 12 / June / 2021, 17:47:14 by srsa_4c »

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #337 on: 13 / June / 2021, 02:20:51 »

@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?

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #338 on: 13 / June / 2021, 10:47:34 »

Quote from: Ant on 13 / June / 2021, 02:20:51

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 entry a1, 32 the first stack param would be at a1 + 32). *~~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.

« Last Edit: 13 / June / 2021, 11:48:11 by srsa_4c »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #339 on: 13 / June / 2021, 18:06:05 »

Quote from: srsa_4c on 13 / June / 2021, 10:47:34

will 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.

Code: [Select]

# 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:

Code: [Select]

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:

Code: [Select]

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,128)
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.

Logged