Overview
This page contains extra information about the Ingenic
JZ4760B.
Some of it may, or may not, apply to the JZ4760. This processor is part of the
IngenicJz47xx line.
The exact differences between the JZ4760 and
JZ4760B are unclear, some of them are very vaguely mentioned in a Ingenic document. The register headers seem to be the best source of information so far.
Boot ROM
The Ingenic ROM uses the XBurst
BootROM USB protocol to upload code, this mode is typically entered by holding a button on boot and serves as a recovery mode.
The JZ4760 and
JZ4760B seem to use exactly the same ROM.
ROM analysis
Disassembly and analysis of the ROM reveals a few interesting features:
- the code uses no stack and no RAM, only registers
- each time a PROGRAM_START1 is executed and the code returns to the caller, the ROM performs a soft-reset by redoing all init again (thus cache content may not be preserved)
- the code setups the D-cache as RAM by cleverly prefilling the cache tags so that the D-cache appears to be mapped at 0x8000000-0x80003FFF.
- PROGRAM_START1 copies D-cache to I-cache by reading the D-cache and filling the I-cache manually using an undocumented cache operation (OP=3 on I-cache). Interesting note: the cache operation is done at intervals of 4-bytes, the data word being loaded in DataLo, thus suggesting that this operation acts as a 'word write' to I-cache.
- The ROM uses an undocumented bit in the CP0 ECC register, it is possible that this bit is related to I-cache to allow for the D-cache to I-cache copy or to enable I-cache writing. It is also possible that it simply disables/bypasses I-cache because the code is running from ROM anyway and this allows to safely write I-cache and then run from it.
- IMPORTANT: despite what the manual says, in USB boot mode, the host must NOT send
VR_SET_DATA_LEN before doing a bulk write, otherwise the result is unpredictable
CPU info
We do not have the entire CPU manual so a lot of details are unclear. Analysis so far yield the following conclusion:
- It supports MIPS32r1
- Despite Release 2 being advertised in Config, none of the new Release 2 instructions work (ext, ei, di, ...). The JZ4780 manual mention that "those were available starting from JZ4770"
- EBASE is supported as per Release 2
- it is mostly compatible with MIPS 4KE
The following points are still being investigated:
- FPU support is not advertised in Config but claimed in the manual
- Vectored interrupts are advertised in Config3 but have not been tested
- The datasheet attached to this page lists the instructions and registers specific to XBurst. Those are mostly SIMD instructions.
Standard CP0 registers
- CONFIG1 present
- MIPS32 release: 2 This is a bit strange since new Release 2 instructions do not work
- MMU type: standard TLB
- kseg0 cacheability: cacheable
- EJTAG present
- watch registers present
- Dcache associativity = 4 ways
- Dcache line size = 32 bytes
- Dcache sets per way = 128
- Icache associativity = 4 ways
- Icache line size = 32 bytes
- Icache sets per way = 128
- Number of MMU entries = 32
- Watch registers implemented It is a bit strange that FPU support is not reported but manuals claims XBurst has a FPU
I have not tested vectored interrupts
Match that of the manual.
Undocumented CP0 registers
The XBurst1 comes into at least two different versions and we don't have the cpu manual. This information comes from reverse engineer, online googling and also from the JZ4780 manual that contains information (although some don't apply).
EBASE (Register 15, Select 1)
The processor comes with a standard EBASE register, as per Release 2. Tests have confirmed that it works.
The JZ4780 has a write gate for EBASE[30] in Config7 but it does not appear to be working on the
JZ4760B.
| Bits |
Name |
Description |
R/W |
| 31 |
MSB31 |
Always read as 1 |
R |
| 30 |
MSB30 |
Alwats read as 0 |
RW |
| 29:12 |
EBASE |
Bit field 29:12 of exception handler base when STATUS[bev] = 0 |
RW |
| 11:3 |
Reserved |
Read as zero |
R |
| 2:0 |
Core_ID |
Read as 0 since JZ4760B only supports CP0 on the first processor |
R |
Config7 (Register 16, select 7)
The processor has a Config7 register that controls a few things. We don't have the full description but the following bits definitely exist.
Some control the BTB (Branch Target Buffer). The JZ4780 has a write gate for EBASE[30] in Config7 but it does not appear to be working on the
JZ4760B.
| Bits |
Name |
Description |
R/W |
| 1 |
BTB_INV |
Writing 1 to this field invalidate all entries of the BTB. Reads as 0 |
W |
| Â 0 |
BTB_EN |
Set to 1 to disable BTB |
 RW |
Unknown (Register 5, Select 4)
Some comment in ingenic's minios suggest this register might be called "big page mode register".
This register has an unknown purpose but it is very important that its value be 0xa9000000 for the JTLB to operate normally. Otherwise the JTLB will be hardwired to 4K pages and the entries are forced to have contiguous EntryLo0 and EntryLo1 (essentially making the TLB not really "joint"). The following two sources confirm the importance of this register:
Automatic analysis result
Most of the data above comes from automatic tests done by hwstub. Here is the raw output.
Output of
./hwstub_shell -q -f lua/xburst.lua -e "XBURST.init()"
XBurst:
PRId: 0x2ed0024f
CPU: JZ4760(B)
Config: 0x80000483
Architecture Type: MIPS32
Architecture Level: Release 2 (or more)
MMU Type: Standard TLB
Config1: 0x3e63318a
MMU Size: 32
ICache
Sets per way: 128
Ways: 4
Line size: 32
DCache
Sets per way: 128
Ways: 4
Line size: 32
FPU: no
Config2: 0x80000000
Config3: 0x20
Vectored interrupt: yes
Config7: 0x0
Output of
./hwstub_shell -q -e 'require("jz/misc"); JZ.misc.enable_sram()' -f lua/xburst.lua -e "XBURST.test_ebase(0x80000000);XBURST.test_ebase(0xb32d0000); exit()" when run with RAM enabled
Testing EBASE...
Disable BEV
SR value: 0x2000fc00
EBASE value: 0x80000000
Value after writing 0x80000000: 0x80000000
Value after writing 0x80040000: 0x80040000
Test result: EBase seems to work
Disable config7 gate: write 0x0 to Config7
Value after writing 0xfffff000: 0xbffff000
Enable config7 gate: write 0x80 to Config7
Value after writing 0xc0000000: 0x80000000
Config7 result: Config7 gate does not work
Exception test with EBASE at 0x80000000...
Writing instructions to memory
Old SR: 0x2000fc00
New SR: 0xfc00
EBASE: 80000000
Before: cafebabe
After: deadbeef
Exception result: Exception and EBASE are working
Testing EBASE...
Disable BEV
SR value: 0x2000fc00
EBASE value: 0x80000000
Value after writing 0x80000000: 0x80000000
Value after writing 0x80040000: 0x80040000
Test result: EBase seems to work
Disable config7 gate: write 0x0 to Config7
Value after writing 0xfffff000: 0xbffff000
Enable config7 gate: write 0x80 to Config7
Value after writing 0xc0000000: 0x80000000
Config7 result: Config7 gate does not work
Exception test with EBASE at 0xb32d0000...
Writing instructions to memory
Old SR: 0x2000fc00
New SR: 0xfc00
EBASE: b32d0000
Before: cafebabe
After: deadbeef
Exception result: Exception and EBASE are working
See also
--
AmauryPouly - 24 Feb 2016
Copyright © by the contributing authors.
