Display (bitmap overlay)

Ant

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

srsa_4c

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:

LOG(%5d):%5u.%02usec(0x%04x)

# 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

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
};

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)

srsa_4c

Ant

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

srsa_4c

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

Ant

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

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

Ant

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.

srsa_4c

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

Ant

srsa_4cAnother poke through chdkptp seemed to survive for longer.

It clears when I send mzrm message to execute handler's code on Zico.

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:

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

reyalp

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.

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.

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

rmem (ximr_debug address) 6272 -f=dump.bin

I also wrote some chdkptp code to extract the values as text for easy diffing:

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

sx710-g7x-ximr-debug-work-1.patch

6.04KB

sx710-ximr-dumps.7z

2.96KB

reyalp

In ximr branch r5983, I adjusted the histogram erase logic to handle histogram modes that display more than one histogram.

philmoz

reyalp
In ximr branch r5983, I adjusted the histogram erase logic to handle histogram modes that display more than one histogram.

Thanks. Google drive builds updated.

pigeonhill

@philmoz

Phil I just posted on my script developments and added a few screen grabs. https://photography.grayheron.net/2021/07/m3-bracketing-exposure-survey-mode.html

These are taken via an HDMI Hollyland Mars X wireless device.

As you can see, the CHDK stuff is offset to the left, other than the central EXIT text.

I wonder if this is fixable, or do I need to just live with it?

Cheers

Garry

philmoz

pigeonhill
As you can see, the CHDK stuff is offset to the left, other than the central EXIT text.

The HDMI bitmap we draw on is wider than the LCD bitmap (480 pixels vs 360 pixels).
Canon centres the live view to maintain the correct aspect ratio for the image. Canon adjusts it's UI element positions so they remain at the same place relative to the live view.

You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.
Most of the CHDK UI positions are fixed relative to the top left corner, so the histogram position for example will not change. The 'exit' text is always centred on the bitmap.

pigeonhill

You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.

I can’t see this is a script fix, eg my script doesn’t write the text in the bottom left, ie the script’s name.

In the camera all is ok.

The shift is only apparent in the HDMI out.

I guess I’ll be living with the ‘feature’ 😀 😉

pigeonhill

@reyalp @philmoz

I wonder if you would consider the following idea?

As you know, when outputting through the HDMI on the M3 there is an offset created, relative to the LCD bitmap.

My thought is to create a new drawing function that globally adjust the x/y position of the stuff that is being drawn and would be called, say, before draw.overdraw() is called.

For EVF and LCD drawing x and y would be zero.

Just a thought.

Cheers

Garry

PS BTW I've added a 'HDMI hack' check in my script to recover the offset, for when I'm recording the HDMI out 😉

You could use the get_gui_screen_width value to check for the wider bitmap and offset the elements drawn by your script.

Thanks @philmoz at least the stuff I draw is now auto centred in all three modes: LCD, EVF and HDMI. The only thing not addressed is the script title box, but I can live with that 😉

Caefix

Caefix
(ximr) 😀 If the AF-frame is stable then the OSDs and menues are stable too ...

Now lib.c has ...

void vid_bitmap_refresh() {
    extern void _transfer_src_overlay(int);
    int n = active_bitmap_buffer;
    _transfer_src_overlay(n);  // *
    _transfer_src_overlay(n^1);
}

Maybe it´s possible to update both buffers only if needed, save time for zebra ...? :-*

   if (!MF && !script_running && power_on) _transfer_src_overlay(n);  // *

reyalp

@Ant asked

Ant
@reyalp
What is the reason not to merge philmoz's branch?

I have been thinking about it recently. IMO, it's a good improvement. I've been using it exclusively on my D6 cams, and I think most users would prefer it.

But some decisions need to be made. Do we make it the standard for all D6/D7 cams. Do we continue to support both drawing methods in the source? I would really prefer not to support both drawing methods, because it's already a big maintenance headache just with two, but the old digic 6 method is probably easier to debug with early in a port.

If we standardize on ximr, a few cameras are unconverted, at least M10, G16, SX60 and the SX280 family cams.

IIRC @srsa_4c also had some unresolved concerns, but I didn't immediately see them scrolling back in the thread.

philmoz

reyalp
If we standardize on ximr, a few cameras are unconverted, at least M10, G16, SX60 and the SX280 family cams.

This is the sticking point IMHO.

If we could find people to test them it would probably not be too hard to add the missing ones.

Otherwise I guess we have to live with three drawing systems.

Phil.

waterwingz

philmoz
If we could find people to test them it would probably not be too hard to add the missing ones.

I still have a couple of working G16's. That's one down , three to go.

Sent from my Pixel 4a using Tapatalk

62ndidiot

Happy to test sx60hs

« Previous Page Next Page »