Display (bitmap overlay) - page 34 - General Discussion and Assistance - CHDK Forum
supplierdeeply

Display (bitmap overlay)

  • 347 Replies
  • 69320 Views
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 »

*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #331 on: 10 / June / 2021, 17:22:55 »
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.

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

*

Offline philmoz

  • *****
  • 3320
    • Photos
Re: Display (bitmap overlay)
« Reply #333 on: 10 / June / 2021, 17:57:31 »
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.

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)


*

Offline philmoz

  • *****
  • 3320
    • Photos
Re: Display (bitmap overlay)
« Reply #334 on: 10 / June / 2021, 18:01:41 »
Just tried resetting several times and problem has gone away.  :)


@pigeonhill


Did you reset the Canon settings or the CHDK settings?

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)

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.


*

Offline srsa_4c

  • ******
  • 4416
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 »

*

Offline Ant

  • ****
  • 490
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?


*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #338 on: 13 / June / 2021, 10:47:34 »
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 »

*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #339 on: 13 / June / 2021, 18:06:05 »
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.

 

Related Topics