PinePhone: Difference between revisions
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
→Power distribution: some stuff about the AXP803 |
→Loading code example: SRAM A contains some stuff you can't overwrite |
||
Line 71:
sunxi-fel write 0x00010000 code.bin
sunxi-fel execute 0x00010000
Why 0x00010000? According to the [https://linux-sunxi.org/A64/Memory_map memory map] this region 0x00010000-0x00017FFF is where the boot ROM normally loads user code, which means it shouldn't conflict with anything used by the boot ROM (e.g. to support the USB interface).▼
Your code can execute BX LR to return back to the boot loader.
Line 78 ⟶ 76:
To see if your toolchain works you can try to run [[User:Immibis/PinePhone Blinky]].
▲Why 0x00010000? According to the [https://linux-sunxi.org/A64/Memory_map memory map] this region 0x00010000-0x00017FFF is where the boot ROM normally loads user code, <s>which means it shouldn't conflict with anything used by the boot ROM (e.g. to support the USB interface).</s> region 0x00010XXX is fine, 0x00011XXX conflicts and breaks USB. Comments in the sunxi-fel tool indicate regions 0x11c00-0x11fff (IRQ stack), 0x15c00-0x16fff (actual stack), and 0x17c00-0x17fff ("something important", probably USB-related data structures or similar) are important. Additionally, the tool uses 0x31400-0x32fff to hold backup copies of these.
It's not clear exactly which parts of memory you can overwrite while still being able to return to FEL mode. [TODO: find out]. Alternatively you could initialize DRAM and then load your code into DRAM, as two separate steps.▼
It can also use 0x11000-0x113FF to hold code and data for more complex commands.
Maybe 0x18000 (SRAM C) is a good load location. 0x19400 bytes (~48k) should be available.
If using SRAM C, don't set 0x01C202C4 (Bus Clock Register1) bit 0x00000001 (Gating Clock VE) to 0 as this seems to make SRAM C inaccessible. I guess it's connected to the video engine?
▲
== Custom bootloader stuff ==
| |||