AJ 5.9 running on 500d -- boots and draws UI!!!

[Andrew Coutts]

current issues:
* aj_lib.c -- g_vram_bank = vram_get_number(2); returns -1 for some
reason, can being overridden now by just specifying the bank as 1. UI
works sometimes as a result.
* where to even start with buttons? already modified gui.c
gui_main_task for 500d.
* in reboot.c -- to get it to boot I had to comment out these in
cstart():

...
set_i_tcm( 0x40000006 );
set_control_reg( read_control_reg() | 0x10000 );

// Install the memory regions
setup_memory_region( 0, 0x0000003F );
setup_memory_region( 1, 0x0000003D );
setup_memory_region( 2, 0xE0000039 );
setup_memory_region( 3, 0xC0000039 );
setup_memory_region( 4, 0xFF80002D );
setup_memory_region( 5, 0x00000039 );
setup_memory_region( 6, 0xF780002D );
setup_memory_region( 7, 0x00000000 );

set_d_cache_regions( 0x70 );
set_i_cache_regions( 0x70 );
set_d_buffer_regions( 0x70 );
set_d_rw_regions( 0x3FFF );
set_i_rw_regions( 0x3FFF );
set_control_reg( read_control_reg() | 0xC000107D );

select_normal_vectors();
...

anyone know what this code is doing? it's not commented out in the 5d2
version****


Screenshots.
initial boot - first time seeing AJ ui in person :D
http://i.imgur.com/lXHST.jpg

after quick g_vram_bank workaround (yay!):
http://i.imgur.com/JFwDe.jpg




what this means:
AJ's code might be better to run on the 500d and 50d since they are
more like the 5d2 than the 550d/60d/600d. I'd really like to have some
kind of hybrid working eventually to implement ML features outside of
LV and maybe get the best of both worlds.

so any testers want to give it a shot? :P

********************************************************************************
*********************************************************************************
********* USE WITH V1.1.0 FIRMWARE ONLY NOT V1.1.1 *********
*********************************************************************************
********************************************************************************
Download:
http://dl.dropbox.com/u/33161628/autoexec.bin

Source Repository:
https://bitbucket.org/coutts/magic-lantern-aj-500d

[Antony Newman]

I guess the easiest way is to go to the following address:
0xFFFF0000 j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory

That routine will probably jump one that I've called AJ_MAP_5D2_MEMORY() ...

.. whose values you'll need to update into your emailed code fragment.

AJ

ROM:FFFF0000 ; Attributes: noreturn thunk
ROM:FFFF0000
ROM:FFFF0000 j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory ; DATA XREF: sub_FF9A992C+90 o
ROM:FFFF0000                                         ; sub_FF9A9B08+5C o ...
ROM:FFFF0000                 LDR     PC, =AJ_bootload_SP_DIGIC_init__n__MAP_5D2_memory
ROM:FFFF0000 ; End of function j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory
ROM:FFFF0000
ROM:FFFF0004
ROM:FFFF0004 ; =============== S U B R O U T I N E =======================================
ROM:FFFF0004
ROM:FFFF0004 ; Attributes: thunk
ROM:FFFF0004
ROM:FFFF0004 j_AJ_UndefinedInstruction               ; DATA XREF: AJ_CopyDataToStorage:loc_FF9C76B4 o
ROM:FFFF0004                                         ; AJ_CopyDataToStorage:off_FF9C7A68 o ...
ROM:FFFF0004                 LDR     PC, =AJ_UndefinedInstruction
ROM:FFFF0004 ; End of function j_AJ_UndefinedInstruction
ROM:FFFF0004
ROM:FFFF0008
ROM:FFFF0008 ; =============== S U B R O U T I N E =======================================
ROM:FFFF0008
ROM:FFFF0008 ; Attributes: thunk
ROM:FFFF0008
ROM:FFFF0008 j_AJ_SWI                                ; DATA XREF: AJ_guess_MediaProperty_eg.Cards:loc_FF92A810 o
ROM:FFFF0008                                         ; AJ_guess_MediaProperty_eg.Cards:off_FF92AA00 o
ROM:FFFF0008                 LDR     PC, =AJ_SWI
ROM:FFFF0008 ; End of function j_AJ_SWI
ROM:FFFF0008
ROM:FFFF000C
ROM:FFFF000C ; =============== S U B R O U T I N E =======================================
ROM:FFFF000C
ROM:FFFF000C ; Attributes: noreturn thunk
ROM:FFFF000C
ROM:FFFF000C j_AJ_PrefetchAbort                      ; DATA XREF: AJ_SRM_StateObj_n_PC_slot+68 o
ROM:FFFF000C                                         ; AJ_SRM_StateObj_n_PC_slot:off_FF8B02E8 o
ROM:FFFF000C                 LDR     PC, =AJ_PrefetchAbort
ROM:FFFF000C ; End of function j_AJ_PrefetchAbort
ROM:FFFF000C
ROM:FFFF0010
ROM:FFFF0010 ; =============== S U B R O U T I N E =======================================
ROM:FFFF0010
ROM:FFFF0010 ; Attributes: noreturn thunk
ROM:FFFF0010
ROM:FFFF0010 j_AJ_DataAbort                          ; DATA XREF: AJ_SRM_StateObj_n_PC_slot+58 o
ROM:FFFF0010                                         ; AJ_SRM_StateObj_n_PC_slot:off_FF8B02E4 o
ROM:FFFF0010                 LDR     PC, =AJ_DataAbort
ROM:FFFF0010 ; End of function j_AJ_DataAbort
ROM:FFFF0010
ROM:FFFF0014 ; ---------------------------------------------------------------------------
ROM:FFFF0014
ROM:FFFF0014 loc_FFFF0014                            ; DATA XREF: AJ_SRM_StateObj_n_PC_slot+48 o
ROM:FFFF0014                                         ; AJ_SRM_StateObj_n_PC_slot:off_FF8B02E0 o
ROM:FFFF0014                 NOP
ROM:FFFF0018
ROM:FFFF0018 ; =============== S U B R O U T I N E =======================================
ROM:FFFF0018
ROM:FFFF0018 ; Attributes: noreturn thunk
ROM:FFFF0018
ROM:FFFF0018 j_AJ_IRQ                                ; DATA XREF: AJ_PTP_PROP_HANDLER__button_options_related__R0.guess.Property+154 o
ROM:FFFF0018                                         ; AJ_PTP_PROP_HANDLER__button_options_related__R0.guess.Property:off_FF92E2D8 o
ROM:FFFF0018                 LDR     PC, =AJ_IRQ
ROM:FFFF0018 ; End of function j_AJ_IRQ
ROM:FFFF0018
ROM:FFFF001C
ROM:FFFF001C ; =============== S U B R O U T I N E =======================================
ROM:FFFF001C
ROM:FFFF001C ; Attributes: noreturn thunk
ROM:FFFF001C
ROM:FFFF001C j_AJ_FIQ                                ; DATA XREF: AJ_SRM_StateObj_n_PC_slot:loc_FF8B0148 o
ROM:FFFF001C                                         ; AJ_SRM_StateObj_n_PC_slot:off_FF8B02EC o ...
ROM:FFFF001C                 LDR     PC, =AJ_FIQ
ROM:FFFF001C ; End of function j_AJ_FIQ
ROM:FFFF001C
ROM:FFFF001C ; ---------------------------------------------------------------------------
ROM:FFFF0020 off_FFFF0020    DCD AJ_bootload_SP_DIGIC_init__n__MAP_5D2_memory
ROM:FFFF0020                                         ; DATA XREF: j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory r
ROM:FFFF0024 off_FFFF0024    DCD AJ_UndefinedInstruction
ROM:FFFF0024                                         ; DATA XREF: j_AJ_UndefinedInstruction r
ROM:FFFF0024                                         ; AJ_SRM_StateObj_n_PC_slot:loc_FF8B0180 o ...
ROM:FFFF0028 off_FFFF0028    DCD AJ_SWI              ; DATA XREF: j_AJ_SWI r
ROM:FFFF002C off_FFFF002C    DCD AJ_PrefetchAbort    ; DATA XREF: j_AJ_PrefetchAbort r
ROM:FFFF0030 off_FFFF0030    DCD AJ_DataAbort        ; DATA XREF: j_AJ_DataAbort r
ROM:FFFF0034                 DCB    0
ROM:FFFF0035                 DCB    0
ROM:FFFF0036                 DCB    0
ROM:FFFF0037                 DCB    0
ROM:FFFF0038 off_FFFF0038    DCD AJ_IRQ              ; DATA XREF: j_AJ_IRQ r
ROM:FFFF003C off_FFFF003C    DCD AJ_FIQ              ; DATA XREF: j_AJ_FIQ r
ROM:FFFF0040 ; ---------------------------------------------------------------------------
ROM:FFFF0040                 NOP
ROM:FFFF0044
ROM:FFFF0044 ; =============== S U B R O U T I N E =======================================
ROM:FFFF0044
ROM:FFFF0044 ; +---------------------------------+
ROM:FFFF0044 ; |  AJ_bootload_SP_DIGIC_init()    | called by j_AJ_bootload_SP_DIGIC_init()
ROM:FFFF0044 ; +---------------------------------+
ROM:FFFF0044 ;
ROM:FFFF0044 ; Attributes: noreturn
ROM:FFFF0044
ROM:FFFF0044 AJ_bootload_SP_DIGIC_init__n__MAP_5D2_memory
ROM:FFFF0044                                         ; CODE XREF: j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory j
ROM:FFFF0044                                         ; DATA XREF: j_AJ_bootload_SP_DIGIC_init____n__MAP_5D2_memory o ...

[Andrew Coutts]

extern unsigned int aj_update_vram_n_bmp_global_variables(void)

{

   g_vram_bank = vram_get_number(2);

   struct vram_info *vram = &vram_info[g_vram_bank];       // raw Vram bank 0 or 1  

   g_bmp_base_addr = (unsigned int) bmp_vram();

   if ( (g_bmp_base_addr == 0) ||  ( (g_bmp_base_addr & 3) > 0)  ) 

   {

      return( 0 );              // Failed to define global vars - don't use aj_lib!

   }

g_vram_bank seems to always have a value of -1. something with vram_get_number isn't working, though the stub is correct and the actual function is identical between the 5d2 and 500d. this is used with the histogram to determine which "bank" is being used currently in the vram (i think?). I can set g_vram_bank to whatever value I like and the histogram seems to work.. so why is vram_get_number() being used here?

[Antony Newman]

Andrew,

I think the use of 2 was arbitrary in as much its seems to point at the right location.

You may find that  vram_get_number(0)  (or 1?) may work.

You could trying dumping all the addresses in the structures ie:

-> vram_info[0]
-> vram_info[1]
-> vram_info[2]

AJ

[Andrew Coutts]

Implemented my own method of finding the currently selected buffer
instead of using vram_get_number() (it doesn't seem to want to return
anything but -1 for me, i'm stumped). I used the
get_fastrefresh_422_buf() from Alex's tree which uses the DMA pointer
address to know which buffer is currently being used. The case
statement returns the unique vram_number of whatever buffer is being
used (as it's referred to in the vram_info[] array).

I found the dma pointer a while ago, see the link below for more 500d
vram information (all of my findings are there).



/
************************************************************************
\
* *
* get_fastrefresh_422_buf() *
* *
* A way to keep track of what vram buffer is currently being used *
* by watching the DMA pointer which always points to the buffer *
* being used currently. Took this from Alex's branch of ML zebra.c *
* *
* For more vram information see: *
* http://magiclantern.wikia.com/wiki/500d_VRAM_Info *
* *
* Replaces AJ's method of calling vram_get_number(2) - didn't work *
* for me on the 500d for some reason. *
* *
* - Coutts *
* *
\************************************************************************/

void* get_fastrefresh_422_buf()
{

//////////////////////////////////////////////////////////////////////////////////
//////////////////////// COUTTS //////////////////////////
//////////////////////////////////////////////////////////////////////////////////
// 0x26a8 updates at roughly 10fps pointing to a new buffer. //
// Each return value is verified to make sure vram->vram_number
corresponds //
// correctly with each buffer address's "number" in which it's
referred to. //
//////////////////////////////////////////////////////////////////////////////////

switch ( (*(uint32_t*)0x26a8) )
{
// first buffer in vram_info array
case 0x41B07800:
return 0; // number = 0 in vram_info array from vram.h

// second buffer
case 0x43738800:
return 1; // number = 1 in vram_info array from vram.h

// third buffer
// maybe not used? oh well, include it anyways.
case 0x43B48800:
return 2; // number = 2 in array.
}
return 0;
} /* end of get_fastrefresh_422_buf() */



/
****************************************************************************
*
aj_update_vram_n_bmp_global_variables()
*

*
*
* Returns: 0 = FAILED to get video
variables *
* 1 =
SUCCESS *

*
*

****************************************************************************/

extern unsigned int aj_update_vram_n_bmp_global_variables(void)
{
g_vram_bank = get_fastrefresh_422_buf();

struct vram_info *vram = &vram_info[g_vram_bank]; // raw Vram
bank 0 or 1

g_bmp_base_addr = (unsigned int) bmp_vram();

if ( (g_bmp_base_addr == 0) || ( (g_bmp_base_addr & 3) > 0) )
{
return( 0 ); // Failed to define global vars -
don't use aj_lib!
}

This seems to work well - the histogram is drawing very smooth now,
and if I print the value of the vram struct:

bmp_printf( FONT_MED, 0, 180, "off_0x00 vram_addr: %x", vram->vram );
bmp_printf( FONT_MED, 0, 200, "off_0x04 vram_width: %d", vram-
>pitch );
bmp_printf( FONT_MED, 0, 220, "off_0x08 vram_pitch: %d", vram-
>width );
bmp_printf( FONT_MED, 0, 240, "off_0x0c vram_height: %d", vram-
>height );
bmp_printf( FONT_MED, 0, 260, "off_0x10 vram_number: %d", vram-
>vram_number );

I can see the vram_addr and vram_number values changing with the dma
address. This suggests that this method seems to be working well :)
I would like to implement this with the HD buffer's DMA pointer.


Homework:
- find struct location of HD vram and use HD vram dma pointer 0x48a0
in same manner as here.



AJ - what do you think? :) Please correct anything that seems to be
wrong (volatile, void, int, etc etc).

[Antony Newman]

Andrew,

If it works it works!  :D

And it should be more likely to show the most current information (eg for Zebras).

HD buffer: I haven't investigated the HD vram dma pointer.  It's bound to be a better method that the one I used (I wrote some sort of 'arcade game' that allowed you to fly through the memory while it worked away in the background guessing which memory was video ram.). 

I did note that some of DIGIC setup structures (which I have not yet had a chance to return to) had the same start addresses as the HD vram (so that the DIGIC could update the memory via dma).    If we are able to find the currently active Digic structure ... we may be able to avoid 'guessing' all the resolution details...

AJ

[Andrew Coutts]

I'm currently investigating what order the camera changes between the
3 buffers by writing the current vram->vram_number to a log file, and
I will see if there is a pattern that it uses. With this, I can tell
ML to write to the buffer that is just about to show, to avoid lagging
behind canon :) this way, it will go like:

-- draw to next buffer in advance before canon switches to use it
-- canon switches buffer, displays our image already drawn in buffer
-- we queue up to expect the next change and repeat

if this works (if my logic is correct), drawing to the screen will be
instant :)
- well at least for histogram - I will have to implement this with the
other buffers that other features use.