NCCH/Extended Header: Difference between revisions

Neobrain (talk | contribs)
Kynex7510 (talk | contribs)
mNo edit summary
 
(5 intermediate revisions by 5 users not shown)
Line 9: Line 9:
All values are little endian unless otherwise specified.
All values are little endian unless otherwise specified.


See also: [https://github.com/profi200/Project_CTR/blob/master/ctrtool/exheader.h]
See also: [https://github.com/3DSGuy/Project_CTR/blob/20f708450b9c6e7f64eafa6c2a8eeb25a630c69a/ctrtool/exheader.h]


{| class="wikitable" border="1"
{| class="wikitable" border="1"
Line 31: Line 31:
| <code>0x500</code>
| <code>0x500</code>
| <code>0x100</code>
| <code>0x100</code>
| NCCH HDR RSA-2048 public key
| NCCH header RSA-2048 modulus
|-
|-
| <code>0x600</code>
| <code>0x600</code>
Line 38: Line 38:
|}
|}


The <code>AccessDesc</code> signature covers the NCCH HDR public key and second ACI. The <code>AccessDesc</code> public key is initialised by the boot ROM.
The <code>AccessDesc</code> signature covers the NCCH header modulus and second ACI. The <code>AccessDesc</code> public key is initialised by the boot ROM.


When loading the exheader, [[FIRM|Process9]] compares the exheader data with the data in the <code>AccessDesc</code> (note that not everything is compared here). When these don't match, an error is returned. The Process9 code handling this validation was updated with [[6.0.0-11|v6.0]]; the only change in this function seems to be the check for the "Ideal processor" field.
When loading the exheader, [[FIRM|Process9]] compares the exheader data with the data in the <code>AccessDesc</code> (note that not everything is compared here). When these don't match, an error is returned. The Process9 code handling this validation was updated with [[6.0.0-11|v6.0]]; the only change in this function seems to be the check for the "Ideal processor" field.
Line 51: Line 51:
| <code>0x0</code>
| <code>0x0</code>
| <code>0x8</code>
| <code>0x8</code>
| Application title
| Application title (default is "CtrApp")
|-
|-
| <code>0x8</code>
| <code>0x8</code>
Line 494: Line 494:
|-
|-
| <code>0b11111111100x</code>
| <code>0b11111111100x</code>
| Map address range
| Map IO/static address range
| Describes a memory mapping like the 0b111111111110 descriptor, but an entire range rather than a single page is mapped. Usually, another 0b11111111100x descriptor follows this one to denote the (exclusive) end of the address range to map, but it has been observed that sometimes the range is not explicitly closed, which presumably indicates a single-page mapping.
| Describes a memory mapping like the 0b111111111110 descriptor, but an entire range rather than a single page is mapped. Another 0b11111111100x descriptor must follow this one to denote the (exclusive) end of the address range to map. Bit20 on the first descriptor: map read-only (otherwise RW), bit20 on the second descriptor: map static (cacheable, otherwise IO if the bit is not set) 
|-
|-
| <code>0b111111111110</code>
| <code>0b111111111110</code>
| Map memory page
| Map IO memory page
| Bits 0-19: page index to map (virtual address >> 12; the physical address is determined per-page according to [[Memory layout]]); Bit 20: Map read-only (otherwise read-write)
| Bits 0-19: page index to map (virtual address >> 12; the physical address is determined per-page according to [[Memory layout]]); Bit 20: Map read-only (otherwise read-write)
|}
|}