IXUS190 porting attempt - page 2 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 10   Go Down

IXUS190 porting attempt

  • 97 Replies
  • 31180 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: IXUS190 porting attempt
« Reply #10 on: 24 / May / 2017, 20:53:47 »
Advertisements
The dancingbits words are at offset 0x45a0 in the ixus190 PRIMARY.BIN.
BTW, finsig_dryos does identify the LEDs, they are in stubs_entry.S as comment. The ixus190 LED GPIOs are indeed the same as the ones used in ixus160.
Logged
*

Offline dorelly2

  • *
  • 16
Re: IXUS190 porting attempt
« Reply #11 on: 26 / May / 2017, 08:57:31 »
Here is my stubs_entry.S (auto-generated for ixus190) for reference:

https://pastebin.com/DdH7zS5P

Quote
Here's what happens when the camera loads diskboot.bin:
- The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).
- Cam is restarted, the bootloader jumps to the loaded code at 0x1900.
- The diskboot file starts with code found in loader/
- The CHDK loader copies the CHDK core to its final location. That is usually the original starting address of the camera's malloc heap. The Canon heap is then adjusted in the boot process so Canon code doesn't overwrite the CHDK core.
- A compatibility check is new in CHDK 1.5 (that's the check_compat call you quoted).
- When the CHDK core is relocated, the CHDK loader starts executing it (platform/camera/main.c).
- After this, a modified copy of Canon boot code is executed (platform/camera/sub/.../boot.c), to start the camera normally, with CHDK running alongside the firmware.

diskboot.bin files are scrambled, the scrambling method is known as "dancing bits".
Sorry, but this explanation is not enough detailed to me (is it verbatim exact generally?). I need some deeper file-by-file, line-by-line execution flow understanding. This is what is critically outdated on http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera and what prevents people like me from developing new ports.

Also, I need the exact meaning of these values:

1. PLATFORMID
2. MAXRAMADDR
3. MEMISOSTART
4. KEYSYS
5. MEMBASEADDR
6. ROMBASEADDR
7. NEED_ENCODED_DISKBOOT

and why some of them are missing from my stubs_entry.S:

1. MEMBASEADDR
2. ROMBASEADDR
3. NEED_ENCODED_DISKBOOT

Example of what I need:

Quote
The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).
What's the code performing that? Built-in program? Then how does this code is aware that "if a file named exactly 'diskboot.bin' is present on the card, it must be loaded to some memory address"? Why to MEMBASEADDR - what so special about this address - why not to the very first byte address?
Quote
Cam is restarted, the bootloader jumps to the loaded code at 0x1900
What code does it and how is this done - line by line (of code)?
Quote
The diskboot file starts with code found in loader/
Which code exactly? What function exactly in this code? How about line-by-line analysis in this function (at least generally)?

... and so on - that's what kind of description I need (based on ixus160 ideally).

Let me try to construct my current guesses:

The general bootup sequence looks (for now) such to me:

Step 1. Built-in code:
Quote
The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).
Then built-in code calls loader/<camera>/entry.S   :o ( ? )

Step 2. loader/<camera>/entry.S :
Code: [Select]
.section .entry

    LDR     SP, =MEMBASEADDR
    BL      check_compat


// ordinary startup...

    MOV     SP, #0x1900
    MOV     R11, #0
    B       my_restart
Let's omit for simplicity these:
Code: [Select]
.section .entry

    LDR     SP, =MEMBASEADDR
    BL      check_compat
But I don't understand what these line do:
Code: [Select]
    MOV     SP, #0x1900
    MOV     R11, #0MOV     SP, #0x1900 means that the stack top is set to 0x1900 address, but why?
but it's clear that:
Step 3.  this line
Code: [Select]
B       my_restartcalls for my_restart() inside loader/<camera>/main.c. Here's the main.c content:
Code: [Select]
#include "../generic/check_compat.c"

extern long *blob_chdk_core;
extern long blob_chdk_core_size;

void __attribute__((noreturn)) my_restart()
{
    {
        long *dst = (long*)MEMISOSTART;
        const long *src = blob_chdk_core;
        long length = (blob_chdk_core_size + 3) >> 2;

  core_copy(src, dst, length);

}

    // restart function
    // from sub_FF83846C via 0x12345678
    asm volatile (
"    MOV     R0, #0x78 \n"
"    MCR     p15, 0, R0, c1, c0 \n"
"    MOV     R0, #0 \n"
"    MCR     p15, 0, R0, c7, c10, 4 \n"
"    MCR     p15, 0, R0, c7, c5 \n"
"    MCR     p15, 0, R0, c7, c6 \n"
"    MOV     R0, #0x80000006 \n"
"    MCR     p15, 0, R0, c9, c1 \n"
"    MCR     p15, 0, R0, c9, c1, 1 \n"
"    MRC     p15, 0, R0, c1, c0 \n"
"    ORR     R0, R0, #0x50000 \n"
"    MCR     p15, 0, R0, c1, c0 \n"
"    LDR     R0, =0x12345678 \n"
"    MOV     R1, #0x80000000 \n"
"    STR     R0, [R1, #0xFFC] \n"
//"    BL      sub_FF896A8C \n"  // nullsub
//"    LDR     R0, =0xFF820000 \n"
"MOV     R0, %0\n"              // new jump-vector
//"    LDMFD   SP!, {R4,LR} \n"
"    BX      R0 \n"
         : : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"
        );

        while(1);
}
I don't understand what core_copy does and why, but I suppose that after comes the camera restart code (which I probably have to substitute from ixus160 to ixus190?)
This line seems interesting:
Code: [Select]
: : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"but I also don't understand what does it do and why.

at least comes
Code: [Select]
while(1);why infinite loop here? So this function is a some kind of "master thread"?

and what happens later - is totally unclear... Reading attempts of http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera bring no result...

I suppose that the next step - some code (which one?) calls startup() function in platform/<camera>/main.c, which then calls boot() function from platform/<camera>/sub/<version>/boot.c  (?) And what next?

Am I understanding right that the diskboot.bin utilizes 2 independent memory regions on the camera RAM:

a. some memory region where diskboot.bin (ISO actually) is loaded from the card.  Is MEMBASEADDR the value that points to its start?
b. some completely another memory region used as a malloc heap for (a) region (loaded ISO). Is MEMISOSTART the value that points to its start?

Code: [Select]
diskboot.bin files are scrambledwhich probably means that we have to scramble the compiled CHDK sources in order to comply with the camera craziness?

PS I can't proceed to whatever disassembling until I have a clear understanding of the whole boot-up process in enough details.
« Last Edit: 26 / May / 2017, 10:19:35 by dorelly2 »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: IXUS190 porting attempt
« Reply #12 on: 26 / May / 2017, 14:26:58 »
Quote from: dorelly2 on 26 / May / 2017, 08:57:31
I need some deeper file-by-file, line-by-line execution flow understanding.
I'll try to answer some specific questions below, but IMO, you only really get this kind of understanding from actually going through the code.
Quote
1. PLATFORMID
http://chdk.wikia.com/wiki/P-ID_(Table)
In CHDK, this is relevant because
1) It's required to generate a usable firmware update file
2) It's used in the CHDK compatibility check.

Quote
2. MAXRAMADDR
Physical memory size. Used for sanity checks, doesn't have to be set correctly right away. Grep the source.

Quote
3. MEMISOSTART
The final location where the CHDK code is loaded in memory.
Quote
4. KEYSYS
An arbitrary identifier for the firmware update file encoding. See platform/fi2.inc.txt
Quote
5. MEMBASEADDR
The address where Canon firmware code initially loads the CHDK binary from DISKBOOT.BIN or PS.FI2. 0x1900 on pre-digic 6 platforms.

Quote
6. ROMBASEADDR
The start of ROM code.
Quote
7. NEED_ENCODED_DISKBOOT
A number identifying the encoding used for DISKBOOT.BIN. See tools/dancingbits.c

Quote
and why some of them are missing from my stubs_entry.S:
The tool generates this file (finsig) doesn't find them, either because they aren't values it is intended to find, or because it isn't able to find them for your camera. Note, you need to have ROMBASEADDR set correctly for finsig to work correctly.

Quote
Quote
The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).
What's the code performing that? Built-in program? Then how does this code is aware that "if a file named exactly 'diskboot.bin' is present on the card, it must be loaded to some memory address"? Why to MEMBASEADDR - what so special about this address - why not to the very first byte address?
This is all done by the Canon firmware, so we have no control over it.
Quote
Which code exactly? What function exactly in this code? How about line-by-line analysis in this function (at least generally)?
CHDK begins execution in loader entry.S.
Quote
But I don't understand what these line do:
Code: [Select]
    MOV     SP, #0x1900
    MOV     R11, #0MOV     SP, #0x1900 means that the stack top is set to 0x1900 address, but why?
Canon startup code uses it, so we have good reason to believe it's safe.

Quote
I don't understand what core_copy does and why, but I suppose that after comes the camera restart code (which I probably have to substitute from ixus160 to ixus190?)
It does what it says on the tin: It copies the CHDK main code from the location it was loaded by the Canon firmware (near MEMBASEADDR, after the loader code, see blobs.S) to it's final location. This copy needs to be done because the original firmware keeps it kernel data around MEMBASEADDR.
Quote
This line seems interesting:
Code: [Select]
: : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"but I also don't understand what does it do and why.
See the gcc inline asm documentation https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm

The important part happens before that:
Code: [Select]
"mov     R0, %0\n"
"BX      R0\n"
%0 refers to the MEMISOSTART value, as described in the doc linked above.

Quote
Code: [Select]
while(1);why infinite loop here? So this function is a some kind of "master thread"?
The inline assembly above that jumps into the main boot code which should never return, so it's really just there to make execution not wander off into memory if something goes badly wrong.

Quote
I suppose that the next step - some code (which one?) calls startup() function in platform/<camera>/main.c, which then calls boot() function from platform/<camera>/sub/<version>/boot.c  (?) And what next?
Correct. Follow the code in boot.c

Quote
Am I understanding right that the diskboot.bin utilizes 2 independent memory regions on the camera RAM:

a. some memory region where diskboot.bin (ISO actually) is loaded from the card.  Is MEMBASEADDR the value that points to its start?
Yes, the CHDK binary is initially loaded at MEMBASEADDR
Quote
b. some completely another memory region used as a malloc heap for (a) region (loaded ISO). Is MEMISOSTART the value that points to its start?
Yes, MEMISOSTART points to final, safe location where the main CHDK binary runs.

The important part is the Canon firmware loads the code only at MEMBASEADDR, and starts executing it. We need the CHDK code at a different location, because we need to be able to re-run the Canon boot sequence and the Canon firmware itself uses memory around MEMBASEADDR. This is also part of why we need to re-run the Canon boot sequence in the first place: when the Canon firmware loads a binary like DISKBOOT.BIn, it trashes it's own kernel memory.
Quote
which probably means that we have to scramble the compiled CHDK sources in order to comply with the camera craziness?
Yes, that's what dancingbits does.

Quote
PS I can't proceed to whatever disassembling until I have a clear understanding of the whole boot-up process in enough details.
I would suggest familiarizing yourself with the firmware disassembly. Understanding the Canon firmware can help you understand why CHDK does the things it does.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12139
    • Waterwingz
Re: IXUS190 porting attempt
« Reply #13 on: 26 / May / 2017, 16:08:03 »
Quote from: reyalp on 26 / May / 2017, 14:26:58
Quote
PS I can't proceed to whatever disassembling until I have a clear understanding of the whole boot-up process in enough details.
I would suggest familiarizing yourself with the firmware disassembly. Understanding the Canon firmware can help you understand why CHDK does the things it does.
FWIW, I'd bet $100 that most of the CHDK ports had their boot-up process simply copied from the nearest camera port without a whole lot of understanding of the process on the part of the person doing the port.   

More power to you for trying to completely understand it but for most people, a cut&paste of another camera's code "just works" and they can get right on to the creating the code it boot.c. 

YMMV of course.

edit : all the posts you are creating here could become the newbie porting guide that does not yet exist.  Keep going - I think you are getting the help you need along the way?
« Last Edit: 26 / May / 2017, 16:10:17 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline dorelly2

  • *
  • 16
Re: IXUS190 porting attempt
« Reply #14 on: 29 / May / 2017, 08:11:17 »
Another new attempt to collect the puzzle.

First of all - I don't understand whether the camera RAM is energy-dependent or not? Why when we load something from the card into the memory and then reboot the camera - our loaded code remains alive somewhere in the camera RAM? So is this a real RAM or somewhat like flash memory?

This is how I currently see the boot-up sequence. Correct me please if I am wrong:

Step 1. The camera (normally) starts the code execution at the zero address (?).

http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera
Quote
When the camera is turned on without the CHDK, it executes the very first bytes of the firmware and thus booting the camera.

Then the Canon firmware does:

Quote
The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).

Step 2. Then the Canon firmware does:

Loads the folder "CHDK" (so called "CHDK core") from the card to the blob_chdk_core address (?). It's probably somewhere near MEMBASEADDR (unclear where exactly, probably right after it).

Step 3. Then loader/<camera>/entry.S is invoked (who calls it?) and calls my_restart() in loader/<camera>/main.c:

loader/<camera>/entry.S:
Code: [Select]
// ordinary startup...

    MOV     SP, #0x1900
    MOV     R11, #0
    B       my_restart
Step 4. my_restart() in loader/<camera>/main.c does this:

Here's loader/<camera>/main.c content for reference: https://pastebin.com/u0ZQUkS4

4.1

loader/<camera>/main.c
Code: [Select]
void __attribute__((noreturn)) my_restart()
{
    {
        long *dst = (long*)MEMISOSTART;
        const long *src = blob_chdk_core;
        long length = (blob_chdk_core_size + 3) >> 2;

  core_copy(src, dst, length);

}
Which means: copy the (RAM-loaded to blob_chdk_core on step 2) CHDK folder to MEMISOSTART (e.g. final CHDK folder location).

4.2

loader/<camera>/main.c
Code: [Select]
asm volatile (....)
restarts the camera in such a way so that when it reboots, it starts to execute the code not from zero address but from MEMBASEADDR (?):

This is probably the code that sets MEMBASEADDR as the new after-reboot-execution-starting point (?):

Code: [Select]
"MOV     R0, %0\n"              // new jump-vector
but what does this statement do:

Code: [Select]
: : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"
is still unclear and why is MEMISOSTART is involved there.

NOTE:

When steps 1 and 2 are done, part of the original Canon firmware gets erased by the CHDK folder content copied from the card. That's why we relocate the CHDK folder loaded content (on step 2) to MEMISOSTART (in the next steps after step 2) and reload the camera. But the diskboot.bin content does not erase anything useful in the RAM (during step 1) and hence does not have to be relocated.

Step 5. I probably found out what's next. srsa_4c states that next
Quote
When the CHDK core is relocated, the CHDK loader starts executing it (platform/camera/main.c).

I found this explanation in the instruction at http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera

Quote
Here we implement the function copy_and_restart() (outdated: actually it is my_restart() inside loader/<camera>/main.c). As arguments it takes the destination, source and size of the CHDK core. It first copies the core to the destination and then executes the slightly adapted reset code. You can typically locate this reset code in the firmware by using your reference port. Once you have found it, you must copy it (or make sure it is the same as the reference) and make sure you change the jump at the end to jump to the start of the core you just copied).

Note that this last jump is to the start of the core which means it will execute the code in core/entry.S next. This code will call the startup() function in platform/<camera>/main.c, which in turn will call the adapted boot code.

Once again: loader/<camera>/main.c content for reference: https://pastebin.com/u0ZQUkS4

I checked it - there's another file named "entry.S" - but inside the core folder! Who could believe it! Oh yeah, if I wanted to make things trickier, I also would name 2 different files with the same name and extension...

Here is it's content:

core/entry.S
Code: [Select]
    .section .entry
#ifndef THUMB_FW
    MOV     R0, #2
    TEQ     R0, #2
    LDR     SP, =MEMBASEADDR
    MOV     R11, #0
#else
    .code 16
    .syntax unified
#endif
    B       startup
So then probably this line

Code: [Select]
: : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"
does this:

Quote
Note that this last jump is to the start of the core which means it will execute the code in core/entry.S next. This code will call the startup() function in platform/<camera>/main.c, which in turn will call the adapted boot code.

Interesting - how exactly does this happen? Why actually "jump is to the start of the core" executes the code in core/entry.S? This is totally unclear to me yet.

Step 6. Then platform/camera/main.c startup() calls boot() in the end. And boot() involves somehow the CHDK core.... (?)

Step 7. Any furter steps are lost in darkness...

SUMMARY:

1. Is it a correct sequence or not? Would someone eventually download the ixus160 chdk sources to check it out?

2. About *.S-files. Why so strange file extension - "*.S"? Does it mean anything? Does Canon firmware directly read it or some user code does so? Why do some *.S-files contain Assembler code while others contain the C code? Wouldn't it be better to set some 2 different file extensions to different content?

I currently found the code that reads and writes some *.S-files with the C-content. But where is the code writing-reading the *.S-files with the Assembler-content?

3. Is the camera really rebooted or it's just some special memory-reset - while keeping the power on (and thus preserving in the energy-dependent memory our previously loaded code)?

4.
Quote
Porting a camera consists of two main phases. The first phase is concerned about making the camera bootable under the control of CHDK code. When this phase is completed, the camera should be able to successfully boot a CHDK where all features are turned off. After that begins the second phase, where important constants and addresses must be determined from the firmware in order to make all features work. It is possible to activate one feature after the other, such as finding key codes to make the keyboard work or finding addresses of the framebuffers to enable graphical output.

How exactly can I perform the "first phase"? I guess I must temporarily comment some code like:

Quote
For testing purposes you probably want to make sure that you have the standard startup() in platform/<camera>/main.c; this function basically just calls the boot() function of boot.c.

Where is the code to comment (for the first phase to run)?
« Last Edit: 29 / May / 2017, 10:35:43 by dorelly2 »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: IXUS190 porting attempt
« Reply #15 on: 29 / May / 2017, 15:37:06 »
Quote from: dorelly2 on 29 / May / 2017, 08:11:17
Another new attempt to collect the puzzle.

First of all - I don't understand whether the camera RAM is energy-dependent or not?
The camera RAM is regular RAM like your computer. Camara "ROM" where the firmware resides is flash memory built into the camera SOC. CHDK does not modify camera ROM.

Quote
Step 1. The camera (normally) starts the code execution at the zero address (?).
It starts at the address configured as the reset address in hardware. This is always in ROM, pointing at a small piece of code called the romstarter which is separate from the main ROM code. This in turn boots the main firmware, which is also in ROM. For older cameras, the romstarter is at 0xFFFF0000, on Digic 6 and some other recent cameras it's at different addresses.
Quote
Then the Canon firmware does:

Quote
The content of diskboot.bin is unscrambled and is copied to MEMBASEADDR (that's 0x1900 on DIGIC II...5).
Correct. Note this happens in the main firmware (not romstarter), after a significant part of the normal Canon boot process is finished. Confusingly, there is also some code which could load a DISKBOOT.BIN in the romstarter, but it is not used in normal cases.

Quote
Step 2. Then the Canon firmware does:

Loads the folder "CHDK" (so called "CHDK core") from the card to the blob_chdk_core address (?). It's probably somewhere near MEMBASEADDR (unclear where exactly, probably right after it).
No. The camera loads DISKBOOT.BIN (or PS.FI2) to MEMBASEADDR. DISKBOOT.BIN contains the the loader code, followed by the binary defined by blob.S (which includes platform ... main.bin). See loader/makefile_loader.inc

Quote
Step 3. Then loader/<camera>/entry.S is invoked (who calls it?) and calls my_restart() in loader/<camera>/main.c:
When the Canon firmware is done loading and decoding DISKBOOT.BIN, it jumps to the address where it just loaded. This is the loader entry.S

Quote
Which means: copy the (RAM-loaded to blob_chdk_core on step 2) CHDK folder to MEMISOSTART (e.g. final CHDK folder location).
Again, all of the main CHDK binary was loaded in DISKBOOT.BIN. The part that is copied is the main CHDK binary (built as platform ... main.bin)


Quote
restarts the camera in such a way so that when it reboots, it starts to execute the code not from zero address but from MEMBASEADDR (?):
It jumps to the code that it just copied MEMISOSTART, which duplicates part of the Canon boot process, with some modification. This is done in platform boot.c

Quote
Code: [Select]
: : "r"(MEMISOSTART) : "memory","r0","r1","r2","r3","r4"
Read the inline assembly code and the GCC docs I linked to understand what this does.

Quote
is still unclear and why is MEMISOSTART is involved there.
That's where the CHDK code was copied to, and where it jumps to.

Quote
When steps 1 and 2 are done, part of the original Canon firmware gets erased by the CHDK folder content copied from the card. That's why we relocate the CHDK folder loaded content (on step 2) to MEMISOSTART (in the next steps after step 2) and reload the camera. But the diskboot.bin content does not erase anything useful in the RAM (during step 1) and hence does not have to be relocated.
This is not correct. It's the DISKBOOT.BIN which overwrites the Canon OS data in RAM, when the Canon firmware loads it. It has nothing to do with the "CHDK folder". The CHDK folder is just a regular folder on the SD card, which CHDK accesses using normal file IO functions after boot.

Quote
I checked it - there's another file named "entry.S" - but inside the core folder! Who could believe it! Oh yeah, if I wanted to make things trickier, I also would name 2 different files with the same name and extension...
That's the entry point for the main code, which was copied to MEMISOSTART.
Quote
Quote
Note that this last jump is to the start of the core which means it will execute the code in core/entry.S next. This code will call the startup() function in platform/<camera>/main.c, which in turn will call the adapted boot code.

Interesting - how exactly does this happen? Why actually "jump is to the start of the core" executes the code in core/entry.S? This is totally unclear to me yet.
As I said before, in loader.c my_restart:
Code: [Select]
"mov     R0, %0\n"
"BX      R0\n"
%0 is MEMISOSTART
BX R0 is an unconditional jump to the address in R0.


Quote
Step 6. Then platform/camera/main.c startup() calls boot() in the end. And boot() involves somehow the CHDK core.... (?)
boot() is in platform ... boot.c
Quote
2. About *.S-files. Why so strange file extension - "*.S"? Does it mean anything? Does Canon firmware directly read it or some user code does so? Why do some *.S-files contain Assembler code while others contain the C code? Wouldn't it be better to set some 2 different file extensions to different content?
.S is the traditional extension for assembly language on *nix and some other platforms. Some of our .S files include C pre-processor macros (normal in GCC environments). They do not include C code.

Quote
I currently found the code that reads and writes some *.S-files with the C-content. But where is the code writing-reading the *.S-files with the Assembler-content?
stubs_entry.S and stubs_auto.S are generated by our tools. All the .S files all compiled using gcc (which invokes the assembler as needed). See the makefiles.

Quote
3. Is the camera really rebooted or it's just some special memory-reset - while keeping the power on (and thus preserving in the energy-dependent memory our previously loaded code)?
Nothing in the boot process does a hard reboot. When we say the camera is re-booted, we mean it runs the Canon boot code (as modified by us) again.
Logged
Don't forget what the H stands for.
*

Offline dorelly2

  • *
  • 16
Re: IXUS190 porting attempt
« Reply #16 on: 30 / May / 2017, 11:01:55 »
I was learning Assembler a long time ago - and surely have trouble understanding some things - especially when it comes to ARM specifics.

I found myself completely not understanding the loader/<camera>/blobs.S:
Code: [Select]
    .globl blob_chdk_core, blob_chdk_core_size

    .section .blob_chdk_core
blob_chdk_core_start:
    .incbin CORE_FILE
blob_chdk_core_end:

    .text
blob_chdk_core_size:
    .long blob_chdk_core_end - blob_chdk_core_start
blob_chdk_core:
    .long blob_chdk_core_startI remember that
Code: [Select]
.section .blob_chdk_core are "labels". But what is
Code: [Select]
.globl blob_chdk_core, blob_chdk_core_size, why comma is here - I don't remember.

I looked into loader/makefile_loader.inc. I partially understand maybe what it does - is it linking the pre-compiled object-files (*.o) in a determined order? Creating DISKBOOT.BIN as the very final result?

Here's its content for reference:

https://pastebin.com/zK99n0jX

Can we learn the order in which the object-files would be linked (one after another) into the final executable (DISKBOOT.BIN?) by looking at this file?

Quote
When the Canon firmware is done loading and decoding DISKBOOT.BIN, it jumps to the address where it just loaded. This is the loader entry.S
This is probably the main question I don't understand. Why? Why when the Canon firmware is done loading and decoding DISKBOOT.BIN, it jumps to loader/<camera>/entry.S ? Because loader/makefile_loader.inc contains its label at the very end?
Code: [Select]
.......
# Define empty recipes for source files (including the makefiles)
# to prevent make from trying implicit rules to create them. Speeds up build process
../makefile_loader.inc: ;
entry.S: ;So what? Is the code execution come to this label ever? I was said that "the Canon firmware loads DISKBOOT.BIN to MEMBASEADDR, decodes it, and ...." and what? "entry.S is called". How exactly? I guess that right after finishing decoding DISKBOOT.BIN, the Canon firmware (probably) executes some loaded chdk-code? What is this code and how Canon firmware knows to call it? This happens before the camera restart surely.

I have a hypothesis: maybe DISKBOOT.BIN is an executable file, and Canon firmware executes it after loading-decoding? This way the code execution could have a chance to reach for the end of the DISKBOOT.BIN (where the entry.S label resides - which probably means calling the in-compiled by that time loader/<camera>/entry.S)? Then loader/<camera>/entry.S launches the restart code etc...
« Last Edit: 30 / May / 2017, 11:15:10 by dorelly2 »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: IXUS190 porting attempt
« Reply #17 on: 30 / May / 2017, 13:31:31 »
Quote from: dorelly2 on 30 / May / 2017, 11:01:55
I was learning Assembler a long time ago - and surely have trouble understanding some things - especially when it comes to ARM specifics.
The  .globl just declares the two symbols as global.

I would suggest turning to google for this kind of thing. ARM makes their documentation available for free, and of course all the gcc stuff is free too.

As waterwingz suggested earlier, you don't actually need to have a deep understanding of every step to make a port. You can just copy the tree and adjust the things that are actually platform specific, which is mostly the .c and .s files and makefile.inc files in the platform directory.

I don't mean to discourage you from trying to understand the whole process, different people take different approaches and understanding the background can certainly be useful.
Quote
This is probably the main question I don't understand. Why? Why when the Canon firmware is done loading and decoding DISKBOOT.BIN, it jumps to loader/<camera>/entry.S ?
The Canon firmware just jumps to the address it loaded the file to (0x1900 for your camera). This address is hard-coded in the Canon firmware, and the reasons Canon chose to do it this particular way are unknown to us.

CHDK is built in such a way that the start of the file contains the code from entry.S and the code is compiled with a load address of 0x1900. This is why the whole blobs.S thing is needed, because the main CHDK code needs to be compiled with a load address of MEMISOSTART, but included (as data) in a binary loader binary which is compiled with a load address of MEMBASEADDR
Quote
Because loader/makefile_loader.inc contains its label at the very end?
Code: [Select]
.......
# Define empty recipes for source files (including the makefiles)
# to prevent make from trying implicit rules to create them. Speeds up build process
../makefile_loader.inc: ;
entry.S: ;
No, this is just minor optimization to make the build process run a little quicker, as the comment says.

Quote
I have a hypothesis: maybe DISKBOOT.BIN is an executable file, and Canon firmware executes it after loading-decoding?
DISKBOOT.BIN is executable ARM machine code, of course, and yes, the Canon firmware executes it by jumping to the first instruction. However, it's a raw binary, not an executable file format like ELF or COFF.
Logged
Don't forget what the H stands for.
*

Offline dorelly2

  • *
  • 16
Re: IXUS190 porting attempt
« Reply #18 on: 31 / May / 2017, 09:47:44 »
The only thing remains unclear to me by that time:
Code: [Select]
CHDK is built in such a way that the start of the file contains the code from entry.SCan you please provide more details on it? How exactly does it happen? I mean how exactly (in the chdk code) does it happen that loader/<camera>/entry.S eventually gets compiled into the very beginning of DISKBOOT.BIN?

I searched all the sourcecodes for a file containing a line with the "entry.S" occurence - and did not find any evidence clearifying why
Quote
CHDK is built in such a way that the start of the file contains the code from entry.S
.
I found only an invocation of another entry.S - which is core/entry.S (uninteresting in this issue), but nothing new about loader/<camera>/entry.S (being discussed now).

Here's what I found:

platform/makefile_sub.inc

Code: [Select]
.FORCE: ;
entry.o: $(core)/entry.S .FORCE
@echo $< \-\> $@
$(CC) $(CFLAGS) -nostdinc -c -o $@ $<I believe that this code is about core/entry.S - not about loader/<camera>/entry.S - right?

Quote
You can just copy the tree and adjust the things that are actually platform specific, which is mostly the .c and .s files and makefile.inc files in the platform directory.
Impossible. How do I know what files exactly to correct and how, if I don't understand the general boot-up workflow?
Logged
*

Offline reyalp

  • ******
  • 14082
Re: IXUS190 porting attempt
« Reply #19 on: 31 / May / 2017, 13:25:29 »
Quote from: dorelly2 on 31 / May / 2017, 09:47:44
The only thing remains unclear to me by that time:
Code: [Select]
CHDK is built in such a way that the start of the file contains the code from entry.SCan you please provide more details on it? How exactly does it happen? I mean how exactly (in the chdk code) does it happen that loader/<camera>/entry.S eventually gets compiled into the very beginning of DISKBOOT.BIN?
Some combination of the LDOPTS in makefile_loader.inc and the stuff in tools/link-boot.ld. Not sure off the top of my head if the actual order of .o files in the link command also matters.

If I needed to know exactly, I'd go off and read the binutils documentation and do some tests. But it already works, so I don't.

If you do need to debug these things for whatever reason, the main.bin.dump files the build creates in loader and platform can be useful. They contain disassembly of the final binaries for the loader and core, respectively.

Quote
Impossible. How do I know what files exactly to correct and how, if I don't understand the general boot-up workflow?
Many people have made ports just by copy/pasting and updating the platform code. I do encourage people to try to understand the bigger picture, but you don't actually need to know how entry.S ends up first in the diskboot.bin or how the core is copied to the final location, because that code is already set up and works.

Updating the platform code mostly means the .c files, including inline asm (codegen files for non digic 6 cameras), #defines in the include files, variables in the platform makefile.inc files, and any stubs not found by the sig finder.
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3 4 5 6 7 ... 10   Go Up
« previous next »
 

Related Topics