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

Display (bitmap overlay)

  • 355 Replies
  • 73507 Views
*

Offline Ant

  • ****
  • 490
Re: Display (bitmap overlay)
« Reply #340 on: 15 / June / 2021, 14:34:12 »
Advertisements
First try, it does not crash, but I can't see if it works.

On M3 I also don't see this...
I placed your function at 0xbff00100 because memory modification after zico_0 blob(0xbff277b8+) causes crash.
Probably this function was not called. Even with debug flag at 0x40c13414.


*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #341 on: 15 / June / 2021, 14:41:02 »
Another Zico logging variant, using sprintf. The following code does not add timestamps.
sprintf can be found by looking up the reference to this string:
Code: [Select]
LOG(%5d):%5u.%02usec(0x%04x)
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

_sprintf: # stub address
.word   0x80A28918
mybuf: # buffer somewhere in memory - there will be issues with xtensa side caches though
.word   0x1feb2400
bufsize: # size of buffer (0x200 is the safety margin)
.word   0x5ff02600 - 0x5feb2400 - 0x200
ptr: # buffer pointer is kept at this address, Xtensa data memory
.word   0xbff07ffc

myhack:

entry   a1, 64  # note: usable area seems 32 bytes less than this due to space reserved for saved registers, when using call8 (caller or callee?)
                # call12 (caller or callee?) further reduces the usable amount (-16 bytes)

l32r    a8, ptr
l32i    a15, a8, 0
l32r    a9, bufsize
sub     a9, a9, a15
bgez    a9, lab1
movi    a15, 0
lab1:
l32r    a10, mybuf
add     a10, a10, a15
l32r    a8, _sprintf
mov     a11, a2
mov     a12, a3
mov     a3, a15 # backup pointer val
mov     a13, a4
mov     a14, a5
mov     a15, a6
s32i    a7, a1, 0
l32i    a2, a1, 64
s32i    a2, a1, 4
l32i    a2, a1, 68
s32i    a2, a1, 8
l32i    a2, a1, 72
s32i    a2, a1, 12
l32i    a2, a1, 76
s32i    a2, a1, 16
callx8  a8
mov     a11, a3 # restore pointer
add     a11, a11, a10
l32r    a12, ptr
s32i    a11, a12, 0
mov     a2, a10
retw
.end
Code: [Select]
unsigned char rawData[98] = {
0x06, 0x04, 0x00, 0x00, 0x18, 0x89, 0xA2, 0x80, 0x00, 0x24, 0xEB, 0x1F,
0x00, 0x00, 0x05, 0x00, 0xFC, 0x7F, 0xF0, 0xBF, 0x36, 0x81, 0x00, 0x81,
0xFE, 0xFF, 0xF8, 0x08, 0x91, 0xFC, 0xFF, 0xF0, 0x99, 0xC0, 0xD6, 0x29,
0x00, 0xF2, 0xA0, 0x00, 0xA1, 0xF8, 0xFF, 0xFA, 0xAA, 0x81, 0xF5, 0xFF,
0xBD, 0x02, 0xCD, 0x03, 0x3D, 0x0F, 0xDD, 0x04, 0xED, 0x05, 0xFD, 0x06,
0x79, 0x01, 0x22, 0x21, 0x10, 0x29, 0x11, 0x22, 0x21, 0x11, 0x29, 0x21,
0x22, 0x21, 0x12, 0x29, 0x31, 0x22, 0x21, 0x13, 0x29, 0x41, 0xE0, 0x08,
0x00, 0xBD, 0x03, 0xAA, 0xBB, 0xC1, 0xED, 0xFF, 0xB9, 0x0C, 0x2D, 0x0A,
0x1D, 0xF0
};
Code: [Select]
zico_mem=0xbff27940 -- free space in zico code memory
zico_dbg_ptr=0x40c13538 -- 0xc13538 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,1024,1,imgfile)
call_event_proc("Fclose_Fut",imgfile)
call_event_proc("memcpy",zico_mem,buf,1024)
call_event_proc("FreeMemory",buf)
poke(0xbff07ffc,0) -- clear our debug counter (used by our xtensa binary)
poke(zico_dbg_ptr,zico_mem) -- this might crash zico in case of caching issues
edit:
Binary fixed to correspond to source. The 4 constants of code (which are model specific) can be found in binary at offset 4.

edit2:
fix the entry instruction (80 -> 64, stack arguments were not picked up correctly due to that)
« Last Edit: 18 / June / 2021, 17:37:22 by srsa_4c »

*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #342 on: 15 / June / 2021, 14:52:50 »
First try, it does not crash, but I can't see if it works.

On M3 I also don't see this...
I placed your function at 0xbff00100 because memory modification after zico_0 blob(0xbff277b8+) causes crash.
Probably this function was not called. Even with debug flag at 0x40c13414.
I'm not sure if 0xbff0xxxx is suitable for code. A mistake in the constants can also result in a crash. In theory, the 0xbffxxxxx ranges don't use the Xtensa cache (but I can be wrong), but regular memory is cached.
Try the sprintf-based version, less chance for mistakes.

*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #343 on: 16 / June / 2021, 17:16:08 »
For example there is a function that parses jedidraw context(0x80af2d24 for EOS M3 101a).
I tried doing the same on m10. The function you mention is only called from a single function (a string "Management information" is referenced near its start). That parent function seems unreferenced, but it has no arguments. It can be called (in theory) if you write its address to an unused mzrm handler pointer (such as TerminateXimr @ 0x80A008B8 (m3 address)) and you call the ARM side function. If you see crashes after poking, you can try things like playback->rec->playback to beat most things out of Xtensa cache.
So, I planted the sprintf-based wrapper to the right function pointer, called the function and ... got nothing. The debug prints seem to be a bit more conditional.
The wrapped sprintf does work if I use it in other function pointers, such as the one that prints the mzrm handlers's names.


*

Offline Ant

  • ****
  • 490
Re: Display (bitmap overlay)
« Reply #344 on: 18 / June / 2021, 07:01:51 »
Another Zico logging variant, using sprintf. The following code does not add timestamps.
sprintf can be found by looking up the reference to this string:

Are you sure this function is really sprintf ?
I was trying to use this function with my arguments placed in a10 and a11 but didn't get any results.

I'm usung xtensa-esp32-elf-gcc8_2_0-esp32-2019r1-win32 toolchain. Hope it's compatible with zico.
Finally I managed to get some information about zico's DryOS:
Code: [Select]
System Memory Information
  Start Address       = 0x00c04008
  End Address         = 0x00c10000
  Total Size          = 0x0000bff8 (    49144)
  Allocated Size      = 0x00003728 (    14120)
  Allocated Peak      = 0x00003728 (    14120)
  Allocated Count     = 0x00000005 (        5)
  Free Size           = 0x000088d0 (    35024)
  Free Block Max Size = 0x000088d0 (    35024)
  Free Block Count    = 0x00000001 (        1)

 Name            ID   State Pri         Wait(ID)      Stack  StackTop StackEnd       SP
GrphErrTas 00000004    WAIT   2  EVENT(00000002)  0168/0400 08 00c07228 00c07628 00c07530
MzrmRcvTas 00000003 RUNNING   3         -------   0510/2000 08 00c05220 00c07220 --------
init       00000002    WAIT  16  SLEEP(00000002)  0288/1000 08 00c04218 00c05218 00c05000
ClkGearAut 00000005   READY  32         -------   00e0/0100 08 00c07630 00c07730 00c076e0
idle       00000001   READY  33         -------   0110/0200 08 00c04010 00c04210 00c04170

[Driver Entry]
  total :   5 (DRV_ENTRY_MAX)
  used  :   2
[Created Devices]
  drvNo  name
     0   /term
[Default Device]
  device name :
[File Descriptor]
  total :  11 (DM_FILE_MAX)
  used  :   3
  open  :   3
vers_dry                 DRYOS version 2.3, release #0055+p6
vers_mk                  2.63
use_smp                  0
act_spi_sem              1
act_spi_event            1
act_spi_mq               1
act_spi_mutex            1
act_spi_cond             0
act_spi_timer            1
act_spi_clock            1
act_spi_isr              0
act_spi_objlist          1
act_spi_objinfo          1
act_spi_objsetname       1
act_timeout              1
act_objname              1
dbg_stack_check          1
dbg_error_check          1
dbg_logging              0
pu_max                   1
sys_mem_start   0x00c04000
sys_mem_max          49152
user_mem_start  0x00c00000
user_mem_max         12940
sys_objs_start  0x00c0328c
sys_objs_end    0x00c04000
priority_max            34
task_max                12
semaphore_max           32
event_max               13
message_q_max            4
mutex_max                0
condition_max            0
timer_max                4
vector_max               0
it4_mbx_max              0
it4_mpf_max              0
it4_mpl_max              0
level_low                0
level_timer              1
level_kern               1
prio_default            16
stack_default         4096
stack_idle             512
stack_init            4096
stack_addr_idle 0x00000000
stack_addr_init 0x00000000
use_barrier              0
barrier_max              0
« Last Edit: 18 / June / 2021, 13:32:48 by Ant »

*

Offline Ant

  • ****
  • 490
Re: Display (bitmap overlay)
« Reply #345 on: 18 / June / 2021, 16:45:42 »
Finally, I got "Management information" by patching 0x80ab96a8 address which points to 0x00c13420.
Something clears the pointer to my function at 0x00C13420. I did not find how.

*

Offline srsa_4c

  • ******
  • 4416
Re: Display (bitmap overlay)
« Reply #346 on: 18 / June / 2021, 17:43:12 »
Finally, I got "Management information" by patching 0x80ab96a8 address which points to 0x00c13420.
Something clears the pointer to my function at 0x00C13420. I did not find how.
Nice results. I also found that the pointer read back as zero despite the poke in script. Another poke through chdkptp seemed to survive for longer. My above sprintf wrapper was buggy due to me changing the entry amount without changing the access distance of stack arguments.

*

Offline Ant

  • ****
  • 490
Re: Display (bitmap overlay)
« Reply #347 on: 18 / June / 2021, 17:57:27 »
Another poke through chdkptp seemed to survive for longer.
It clears when I send mzrm message to execute handler's code on Zico.

Quote
My above sprintf wrapper was buggy due to me changing the entry amount without changing the access distance of stack arguments.
I used simple version without stack arguments:
Code: [Select]
.text
.begin
.align  4

j       myhack

.align  4

.literal_position

_sprintf: # stub address
.word   0x80a27088
ptr: # buffer pointer is kept at this address
.word   0x803A0010
.align  4

myhack:

entry   a1, 0x50
               

l32r    a8, ptr
l32i    a9, a8, 0

l32r    a8, _sprintf

mov     a15, a6
mov     a14, a5
mov     a13, a4
mov     a12, a3
mov     a11, a2
mov     a10, a9

callx8  a8

l32r    a8, ptr
l32i    a9, a8, 0

add     a9, a9, a10
s32i    a9, a8, 0
movi    a2,0x0

retw
.end

I have not seen more than three arguments yet...
« Last Edit: 18 / June / 2021, 17:59:49 by Ant »


*

Offline reyalp

  • ******
  • 13290
Re: Display (bitmap overlay)
« Reply #348 on: 24 / June / 2021, 01:43:02 »
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.
Worked on this, and resolved for sx710 in r5968. g7x appears very similar (with slight variation because native LCD aspect is 3:2), but I haven't gone through all the permutations yet.

Some observations:
When sx710 or g7x is rendering to from YUV buffer (layer bitmap == fw_yuv_layer_buf), the layer always appears to be layer 1, not layer 0. Layer 0 is an RGB buffer (presumably, stuff like grid lines that doesn't get the extra scaling). This means that CHDK needs to copy layer 0 to get appropriate RGB defaults.

The names of numer* and denom* seem to be backwards. When drawing to the YUV buffer (output_buffer ==  fw_yuv_layer_buf), numerx and numery are 67, denomx and denomy are 60.
This scales down the original UI from the RGB buffer to accommodate the margins specified by dst_x, dst_y ( 42, 28 in SDl 56, 28 in HDMI). E.g. for height (28*2 + 480) * 60 / 67  = 480.

When drawing to the YUV buffer (output_buffer ==  fw_yuv_layer_buf), the RGB input layer is layer 1, and layer 0 is not enabled.

Changing layer.height does not appear to be required or effective.
Code: [Select]
ximr->layers[1].height = 240; on the YUV layer had no visible impact on the output.

I noticed the values at offsets 0x248 and 0x24a seem to be a height and width of some sort. When the rendering to from YUV buffer (layer bitmap == fw_yuv_layer_buf), they have values like 960x480 or 720x480 on sx710. In other cases they are 0. I haven't tried changing them.

On sx710, low res HDMI out appears to be identical to analog out as far as the ximr structure is concerned. Both of these use 720x480 (on a 736 buffer) for live view and the final bitmap, rather than 640x480 like the normal live view. The final output is presumably still intended to be 4:3.

For FHD HDMI, the final output is 960x540, but y is scaled by 54/48, so the CHDK input layer needs to be 240 (upscaled by 2 in the layer.)

Tools:
I used the attached patch for debugging. This is intended for the non-ximr trunk, to examine how the default firmware behaves in various modes. It records a circular buffer with a header (call count, tick, display type, message number) and the ximr_context structure. I also used this to experiment with ximr_context values, poking them in a function called from do_ximr_debug to avoid additional confusion from the CHDK stuff.

I captured this using up the ximr_debug address and dumping it with rmem, like
Code: [Select]
rmem (ximr_debug address) 6272 -f=dump.bin

I also wrote some chdkptp code to extract the values as text for easy diffing:
Code: [Select]
!xd=require'extras/ximrdesc'
!xd.export('sx710-hdmisd1.bin')
Note this requires chdkptp from svn 1026 or later, and expects .bin file to have the header as described above (although adapting it to work on just a xmir_context would be simple).

Example dumps of going from LCD to TV out and LCD to HDMI are attached.
« Last Edit: 24 / June / 2021, 01:47:13 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13290
Re: Display (bitmap overlay)
« Reply #349 on: 04 / July / 2021, 18:54:30 »
In ximr branch r5983, I adjusted the histogram erase logic to handle histogram modes that display more than one histogram.
Don't forget what the H stands for.

 

Related Topics