Getting CPU configuration from CP15

[reyalp]

Here is a preliminary patch (against juciphox 481) to interrogate the System Control Coprocessor, also know as CP15.

Also attached is the resulting CPUINFO.TXT from my a540

See http://infocenter.arm.com/help/topic/com.arm.doc.ddi0155a/DDI0155.pdf for the meanings of the various fields. It's quite possible (even likely!) that I've messed up in the decoding of one or more fields. When in doubt, consult the hex values.

I'd be interested to see what you get on a Digic-III camera.

[fudgey]

Hm I tried patch -p0 < cpuinfo-pre-1.patch  on juciphox 482 (which compared to 481 is the same for the files the patch changes) but it failed at core/gui.c and include/platform.h...

[whim]

After applying the patch against juciphox482 manually, the compiler (standard Windows devkit) gives me:
(Murphy says this is more likely to happen if you're dying to try it out  )

cpuinfo.o: In function `cpuinfo_write_file':
cpuinfo.c:(.text+0xe4): undefined reference to `debug_read_cpuinfo'
collect2: ld returned 1 exit status
E:\CHDK\gcc\bin\gmake[1]: *** [main.elf] Error 1
gmake: *** [all-recursive] Error 1

wim

debug_read_cpuinfo(...) is declared 'void' in platform.h, which is included in both lib.c and cpuinfo.c,
and debug_read_cpuinfo(...) is defined in lib.c ...
shouldn't cpuinfo.c 'see' an 'external void' declaration ?

[reyalp]

You probably have to build clean, since lib.c is actually included and the makefiles don't have include deps. The patch is from tortoise which may have confused gnu patch ?

edit: beware of line endings too, the tree seems to be randomly mixed dos and unix and no eol-style:native set in svn.

[chr]

Hi reyalp!

This information is very helpful! I'm now compiling chdk with -mcpu=arm946e-s and now gcc eats "strd"

Well, lets see what happens if I run this in qemu *g*

[fudgey]

edit: beware of line endings too, the tree seems to be randomly mixed dos and unix and no eol-style:native set in svn.

Hm yes well it does complain about those for all the files, just fails those two.

[reyalp]

Turns out some platforms don't include generic/lib.c

If you put the debug_read_cpuinfo in some other file (probably needs to be arm, not thumb) it should be fine.

[PhyrePhoX]

s3is text attached.

[reyalp]

All the cameras check so far (s3is, sx100is and a540) appear to be identical CPUs, the only difference being slightly different memory protection configuration because of differing ROM addresses.

[reyalp]

Brief summary for those aren't sure what all the stuff in CPU info means:
All cameras reported so far use an ARM946ES rev 1 CPU, with 8k of instruction and data cache (4 way associative, 8 words/line), 4k instruction and data of "tightly coupled memory"

This is an ARM architecture 5TE chip.
Note: ARM model numbers, like ARM946ES should not be confused with ARM architecture versions, like ARMv5TE.

The TE suffix means that ARM DSP Instruction Set Extensions are available.

The implementor (=ARM) and variant (=0) fields suggest this is a plain jane implementation, at least as far as arm code is concerned.

A memory protection (MPU) unit is present, a memory management unit (MMU) is not.

Clock speed is unknown, but strings in my ROM suggest variable between 18mhz and 72mhz (but there are three different ones, H, L and M, and they might refer to base values to which multipliers are applied. The arm docs mention HCLK and CLK) The addresses which get/set these seem pretty obvious, so I may have more on that later.

Intentionally self-replying in case someone wants to move the svn stuff to a different thread

[chr]

Hi!

Running qemu turns out, that some of the coprocessor registers are not supported.

@reyalp: yes, there are some bugs: The regions base addresses are all wrong:

Code: Text

1. Protection Region 0 0x0000003D
2.   Enable               0x1 1
3.   Size                 0x1E 30 [2G]
4.   Undef0_7             0x0 0
5.   Base                 0x0 0
6. Protection Region 1 0xC000002F
7.   Enable               0x1 1
8.   Size                 0x17 23 [16M]
9.   Undef0_7             0x0 0
10.   Base                 0x60000 393216
11. Protection Region 2 0x00000031
12.   Enable               0x1 1
13.   Size                 0x18 24 [32M]
14.   Undef0_7             0x0 0
15.   Base                 0x0 0
16. Protection Region 3 0x10000031
17.   Enable               0x1 1
18.   Size                 0x18 24 [32M]
19.   Undef0_7             0x0 0
20.   Base                 0x8000 32768
21.  
22.  

Here's my manual interpretation of the sd1100 firmware, init camera:

Code: C

1. void __attribute__((naked,noinline)) sub_FF81000C_my() {
2.         asm volatile (
3.                 "ldr    r1,  =0xc0410000 \n"
4.                 "mov    r0, #0  \n" // ; 0x0
5.                 "str    r0, [r1] \n"
6.                
7.                 // disable cache, MPU, etc.
8.                 "mov    r1, #120        \n" // ; 0x78 // sets SBO "should be one" only
9.                 "mcr    15, 0, r1, cr1, cr0, {0} \n"
10.  
11.                 "mov    r1, #0  \n" // ; 0x0
12.                 "mcr    15, 0, r1, cr7, cr10, {4} \n"// drain write buffers
13.                 "mcr    15, 0, r1, cr7, cr5, {0} \n" // flush icache
14.                 "mcr    15, 0, r1, cr7, cr6, {0} \n" // flush dcache
15.  
16.                 // define Protection Regions 0-5
17.                 "mov    r0, #61 \n" // ; 0x3d                   // size 2GB base 0x0
18.                 "mcr    15, 0, r0, cr6, cr0, {0} \n" // prot. mem reg. 0
19.                 "mov    r0, #-1073741777        \n" // ; 0xc000002f // size 16M base 0xc0000000
20.                 "mcr    15, 0, r0, cr6, cr1, {0} \n"
21.                 "mov    r0, #49 \n" // ; 0x31                   // size 32M base 0x0
22.                 "mcr    15, 0, r0, cr6, cr2, {0} \n"
23.                 "ldr    r0,  =0x10000031 \n"                    // size 32M base 0x10000000
24.                 "mcr    15, 0, r0, cr6, cr3, {0} \n"
25.                 "mov    r0, #1073741847 \n" // ; 0x40000017     // size  4k base 0x40000000
26.                 "mcr    15, 0, r0, cr6, cr4, {0} \n"
27.                 "ldr    r0,  =0xff80002d \n"                    // size  8M base 0xff800000
28.                 "mcr    15, 0, r0, cr6, cr5, {0} \n"
29.  
30.                 "mov    r0, #52 \n" // ; 0x34        // regions 2,4,5
31.                 "mcr    15, 0, r0, cr2, cr0, {0} \n" // data cache
32.                 "mov    r0, #52 \n" // ; 0x34
33.                 "mcr    15, 0, r0, cr2, cr0, {1} \n" // instr cache
34.  
35.                 // write buffer ctrl
36.                 "mov    r0, #52 \n" // ; 0x34        // regions 2,4,5
37.                 "mcr    15, 0, r0, cr3, cr0, {0} \n"
38.                 // Region prot. r/w
39.                 "ldr    r0,  =0x03333330 \n"         // region 0,7 = --, 1-6 = rw
40.                 "mcr    15, 0, r0, cr5, cr0, {2} \n" // data access
41.                 "ldr    r0,  =0x03333330 \n"
42.                 "mcr    15, 0, r0, cr5, cr0, {3} \n" // instr access
43.  
44. // This one is in every boot.c: "Changes CPU speed?" - nope!
45.                 "mrc    15, 0, r0, cr1, cr0, {0} \n"
46.                 "orr    r0, r0, #4096   \n" // ; 0x1000 // enable L1 instruction cache
47.                 "orr    r0, r0, #4      \n" // ; 0x4        // L1 unified/data cache enable
48.                 "orr    r0, r0, #1      \n" // ; 0x1        // MMU or Protection Unit enable
49.                 "mcr    15, 0, r0, cr1, cr0, {0} \n"
50.  
51.                 // set TCM data region register
52.                 // addr = 0x40000000
53.                 // size 4K
54.                 "mov    r1, #1073741830 \n" // ; 0x40000006
55.                 "mcr    15, 0, r1, cr9, cr1, {0} \n"
56.  
57.                 // set TCM instruction region
58.                 // smart cache(?)
59.                 // size 4K base 0x0
60.                 "mov    r1, #6  \n" // ; 0x6
61.                 "mcr    15, 0, r1, cr9, cr1, {1} \n"
62.                 // enabel TCM
63.                 "mrc    15, 0, r1, cr1, cr0, {0} \n"
64.                 "orr    r1, r1, #327680 \n" // ; 0x50000 // DRAM (bit[16]), IRAM (bit[18])
65.                 "mcr    15, 0, r1, cr1, cr0, {0} \n"
66.  

So I guess, the ixus80-sd1100 has got 32MB RAM.

[reyalp]

Hi!

Running qemu turns out, that some of the coprocessor registers are not supported.

@reyalp: yes, there are some bugs: The regions base addresses are all wrong:

Those are the values of the base address field, which is NOT the actual base address.

Actually, the base address is combined with the other fields, so if you just ignore the lower part of the registers, you get the correct base address.

I actually updated cpuinfo.c to reflect this after posting. Sorry for not making that clear from the start. Your manual decoding looks very similar to mine for the a540 (interestingly, the ROM region on mine starts at FF8 even though the actual ROM starts at FFC)

On my system, the HCLK, MCLK and LCLK can be read like this:

Code: [Select]

+    if(conf.debug_display == DEBUG_DISPLAY_CLOCKS) {
+        sprintf(sbuf,"hclk %d",*(int *)(0xC0400044));
+     draw_string(16,16,sbuf, conf.osd_color);
+        sprintf(sbuf,"lclk %d",*(int *)(0xC0400048));
+     draw_string(16,32,sbuf, conf.osd_color);
+        sprintf(sbuf,"mclk %d",*(int *)(0xC040004c));
+     draw_string(16,48,sbuf, conf.osd_color);
+ }
LCLK was the only one I could see changing on the fly. The values are an enum: = 72, 1=36, 3=18. 2 is a mystery You can look for "printclock" to check the addresses.

edit: here's a bit from my notes on the a540 memory layout

Code: [Select]

0x0000 0000 region 0 start. -- nocache nobuf
0x0000 0000 region 2 start. RW cache buf
0x0000 0000 ITCM start
0x0000 0FFF ITCM end
0x0000 1900 Copied from FFEF3DF0 (firmware code + init data)
0x0000 D210 Zeroed (firmware BSS ?)
0x0009 22CC end zeroed
0x0009 22D0 chdk start
0x000E 72D0 chdk end
0x01FF FFFF region 2 end / RAM end
0x1000 0000 region 3 start. RW nocache nobuf
0x103C 79A0 bitmap fb start
0x105B 8AC0 raw buffer start
0x10D1 33B0 raw buffer end
0x105F 17A0 viewport fb start
0x11FF FFFF region 3 end
0x4000 0000 region 4 start. RW cache buf
0x4000 0000 DTCM start
0x4000 0FFF DTCM end
0x4000 0FFF region 4 end
0x7FFF FFFF region 0 end
0xC000 0000 region 1 start. RW nocache nobuf
0xC020 0000 ? mmio ?
0xC040 0000 ? mmio ?
0xC0FF FFFF region 1 end
0xFF80 0000 region 5 start. RW cache buf
0xFFC0 0000 ROM start
0xFFEF 3DF0 copied data start
0XFFEF F6FF end
0xFFFF FFFF region 4 / ROM ends


[chr]

Hi!

Running qemu turns out, that some of the coprocessor registers are not supported.

@reyalp: yes, there are some bugs: The regions base addresses are all wrong:

Those are the values of the base address field, which is NOT the actual base address.

Actually, the base address is combined with the other fields, so if you just ignore the lower part of the registers, you get the correct base address.

I actually updated cpuinfo.c to reflect this after posting. Sorry for not making that clear from the start. Your manual decoding looks very similar to mine for the a540 (interestingly, the ROM region on mine starts at FF8 even though the actual ROM starts at FFC)

But finally we understood what was wrong I was very confused about the cp settings because I was looking in the ARM reference. The 946e-s is correct. The documents are a 'bit' different.

The ROM is 8MB but usually udumper just extract the part we need for porting. I also looked at the rest of it and I guess that stuff is simply before FFC in your cam. I found a lot of thumb code, i18n stuff and very interesting: the missing part of the boot process! Funny, the damn diskboot.bin decoding exists there a second time.

Here, this piece has a funny magic:

ffff0000:   ea000001    b   ffff000c <_binary_ffdd_start+0x21000c>
ffff0004:   e59f02a4    ldr r0, [pc, #676]  ; ffff02b0: (ffff3308)  **"orldthewuer conq" 
ffff0008:   e1a0f00e    mov pc, lr

Here, some strings:

Code: [Select]

ffff05b4 #RomStarter Ver1.02 for EC243
ffff05d4 UART loopback switch ON...
ffff05f4 UART loopback switch OFF...
ffff0614 Rescue Loader
ffff0628  Signature is OFF...
ffff0752 < Verify Error >
ffff076a Start Program on RAM
ffff08ba !!!!Mount SD-Card ERROR
ffff08d6 -- -------------------------
ffff08f4 DISKBOOT.BIN
ffff0904 DISKBOOT.BIN is started.
ffff0920 --- DISKBOOT.BIN start ABORT!!! ---
ffff0948 ROMWRITE.BIN
ffff0958 ROMWRITE.BIN is started.
ffff0974 --- ROMWRITE.BIN start ABORT!!! ---
ffff099c UPGRADER.BIN
ffff09ac UPGRADER.BIN is started.
ffff09c8 --- BIN FILE LOAD ERROR ---
ffff09e8 --- UPGRADER.BIN start ABORT!!! ---
ffff0da4 DISKBOOT.BIN ReadError
ffff0dc0 MBR ReadError
ffff0dd4 BootSector ReadError
ffff0dec FORMAT ERROR (NOT FAT12/16)
ffff0e0c ROOTDIR  ReadError
ffff0e24  Not Found
ffff0e34 FAT  ReadError
ffff0e48 DiskBoot Copy ERROR
ffff0e62  Cluster = 0 : Free Space!!!
ffff1130 SD-Card is not Ready. (ACMD41: WAIT BUSY TIMEOUT)
ffff1168 GET CID ERROR
ffff1178 GET RCA ERROR
...
ffff2015  CheckSip is performed.
ffff2031  Is it all right? (N/y)
ffff2171 >> debug shell startted <<
ffff2644  [OK]
ffff264c  [NG]
ffff2654 Adr:
ffff265c ,Write:
ffff2664 ,Read:
ffff2b9d  FROM sum is
ffff2bb5  Data bus check for all DRAM cell :
ffff2bdd  Address bus check for all DRAM cell :
ffff2c09  Data bus check (Simple version) :
ffff2c31  Address bus check (Simple version) :
ffff2dc1  Writing to ROM :
ffff2ddd  SiP check start
ffff2df0 UUUU
ffff2df5 Test Case :
ffff2e05  Write data is 0x55555555
ffff2e21  Write data is 0xAAAAAAAA
ffff2e3d  Write data is 0x00000000
ffff2e59  Write data is 0xFFFFFFFF
ffff2fe0 gaonisoy  R
ffff3003 (  R"
ffff30ea aB@02
ffff31e5  ?     Help
ffff31ee  h     Help
ffff31f7  d <adr> <size>    Dump memory
ffff3213  e <adr>   Edit memory
ffff3228  i  adr        Input
ffff3237  o  adr  data  Output
ffff324c  r <adr>   Rom edit (A bit is corrected to 0)
ffff3278  q     Quit ( =Reset )
ffff328c  c     CheckSiP ( don't return! )
ffff32ab --- example ---


[reyalp]

But finally we understood what was wrong I was very confused about the cp settings because I was looking in the ARM reference. The 946e-s is correct. The documents are a 'bit' different.

Yes, I noticed that the generic docs seemed to give rather different descriptions of some of those things than the 946es tech ref. Some of that has to do with whether the system has an MMU or not AFAIK, but I was definitely confused trying to interpret the CP15 stuff before I looked at the 946 doc.

The ROM is 8MB but usually udumper just extract the part we need for porting. I also looked at the rest of it and I guess that stuff is simply before FFC in your cam. I found a lot of thumb code, i18n stuff and very interesting: the missing part of the boot process! Funny, the damn diskboot.bin decoding exists there a second time.

Some cameras are configured with a 4 meg ROM area starting at FFC. I guess I'll try dumping the full 8 megs on mine at some point. The sx100 cpuinfo attached here for example (which is a bit strange because it's a digic III/dryos cam  )