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.

It is currently not supported on mainline Linux, and is not required to run mainline Linux either.

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?

Toolchain

The upstream GCC does not support OpenRISC at the moment. So the OpenRISC support exists in a separate fork of GCC which can't be contributed upstream. The reason is explained in the #openrisc irc log from 2016-11-25:

olofk	Everyone, except for one guy has given permission for copyright assignment. Unfortunately, his work is very early in the development, so technically the rest is based upin that
wbx	and this guy is no longer interested in or1k?
olofk	The latest idea we had was to see if the stuff he wrote has actually been replaced by other patches
olofk	He is actually running very much involved, as he works for a company that makes proprietary versions of OpenRISC
wbx	isn't is possible to convince the guy to just offer his code as public domain, so no special fsf agreement required.
olofk	No. His standpoint is that he doesn't want to give up his ownership of the code
olofk	Which of course is just pure fucking bogus
wbx	so he thinks his company benefits from these actions so that toolchain support isn't upstream or what?
wbx	i don't understand such actions from people working with open source.
olofk	Well, me neither. But there is not much more we can do to convince him :/

The forked GCC is still a GPL licensed free software, so using it is perfectly legal (the linux-sunxi wiki provides installation instructions). But packaging a usable OpenRISC toolchain in Linux distributions (such as Debian) is another story because this may involve some political arm wrestling.

In the mean time binutils already has OpenRISC support. Yay for some cool assembly programming!

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

Personal tools
Namespaces

Variants
Actions
Navigation
Tools