AR100

From linux-sunxi.org
Jump to: navigation, search

Contents

Overview

The AR100 core is responsible for managing deep power save modes where the rest of the SoC is shut down. It's an OpenRISC based core with code loaded into internal SRAM.

Specifications

  • Name: AR100
  • Architecture: OpenRISC 1000
  • Implementation: OR1200 rev 1
  • Cache: 4K icache, no dcache
  • MMU: not present
  • FPU: not present
  • Byte ordering: Internally big endian. Byte-swapped on the data & instruction busses to little endian.
  • Instruction set(s) support: ORBIS32
  • Multiply-Accumulate (MAC) unit
  • Debug unit
  • Power management
  • Interrupt controller
  • Timer

SPR data

SPR VALUE Decoded
SPR_VR 0x12000001
SPR_UPR 0x00000765
SPR_CPUCFGR 0x00000020
SPR_DMMUCFGR 0x00000000
SPR_IMMUCFGR 0x00000000
SPR_DCCFGR 0x00002600
SPR_ICCFGR 0x00002640

Memory Map

  • Have access to the same I/O as the main A31 core
  • Have access to the DRAM
  • All accesses are automatically byteswapped

A31

ARM address space OpenRISC address space Size Description Performance notes
Start End Start End
0x00040000 0x00041fff 0x00000000 0x00001fff 8 KiB Interrupt vectors. Only one word at each 0x100 boundary
0x00042000 0x00043fff 0x00002000 0x00003fff 8 KiB Reserved
0x00044000 0x00053fff 0x00004000 0x00013fff 64 KiB SRAM A2 One read costs exactly 3 cycles
0x00020000 0x0002ffff 0x00020000 0x0002ffff 64 KiB SRAM B One read costs ~13 cycles for 300 MHz OpenRISC core and 200 MHz AHB1
0x00000000 0x00007fff 0x00040000 0x00047fff 32 KiB SRAM A1 One read costs ~13 cycles for 300 MHz OpenRISC core and 200 MHz AHB1
0x40000000 0xbfffffff 0x40000000 0xbfffffff 2 GiB DRAM One read costs ~53 cycles for 300 MHz OpenRISC core and 360 MHz DRAM

H3

ARM address space OpenRISC address space Size Description Performance notes
Start End Start End
0x00040000 0x00041fff 0x00000000 0x00001fff 8 KiB Interrupt vectors. Only one word at each 0x100 boundary
0x00042000 0x00043fff 0x00002000 0x00003fff 8 KiB Reserved
0x00044000 0x0004bfff 0x00004000 0x0000bfff 32 KiB SRAM A2 One read costs exactly 3 cycles
0x00000000 0x0000ffff 0x00040000 0x0004ffff 64 KiB SRAM A1 One read costs ~25 cycles for 300 MHz OpenRISC core and 200 MHz AHB1
0x40000000 0xbfffffff 0x40000000 0xbfffffff 2 GiB DRAM One read costs ~60 cycles for 300 MHz OpenRISC core and 672 MHz DRAM

To be investigated: something seems to be weird about the SRAM A1 and DRAM access times in H3 when compared to A31. Maybe the MBUS clock speed makes some difference too?

Clocking

The CPU clock can be configured with a register referenced as CCMU_CPUS_CFG in the Allwinner sun6i Linux source code.

CCMU_CPUS_CFG

Address: 0x01f01400

Name Bit Read/Write Default (Hex) Values Description
Reserved 31:18
CCMU_CPUS_CLKSRC 17:16 Read/Write 0x01 
    00 = LOSC (32 KHz)
    01 = HOSC (24 MHz)
    10 = PLL6/POSTDIV
    11 = PLL6/POSTDIV
Clock source
Reserved 15:13
CCMU_CPUS_POSTDIV 12:8 Read/Write 0x00 
    00000 = 1
    00001 = 2
    ...
    11111 = 32
Post divide
Reserved 7:6
CCMU_CPUS_DIV 5:4 Read/Write 0x00 
    00 = 1
    01 = 2
    10 = 4
    10 = 8
Clock divide ratio
Reserved 3:0

Known issues

It is a quite old OpenRISC core so likely have many issues - exceptions in delay slots?

Reverse engineering of firmware

To ease reverse engineering of the firmware for H3, you can use script that takes arisc_sun8iw7p1.bin file (available in the lichee h3 sdk from Draco) and produces readable pseudocode. Pseudocode is split into cross-referenced functions and basic blocks, code within basic blocks is emulated and register assignments use evaluated values if known. Memory and register addresses are renamed based on the map of known locations. Most of the functions are named based on their purpose.

Code can be used to understand the suspend/resume function in H3 in particular and write a mainline implementataion.

It is available on github: megous/h3-ar100-firmware-decompiler

Documentation

Links

Retrieved from "http://linux-sunxi.org/index.php?title=AR100&oldid=17748"
Personal tools
Namespaces

Variants
Actions
Navigation
Tools