DarKE/ingenic-usbboot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add option to dump partitions from the creality k1/max

Browse Source
This commit is contained in:
ballaswag
2023-09-26 23:15:12 -07:00
parent 1bfdf69b1e
commit 5d5a1234fe
3 changed files with 110 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+41 -2
View File
@@ -1,4 +1,4 @@
# ingenic-usbboot
# Creality K1 (X2000E) usbboot tool
## Building
`make`
@@ -12,7 +12,7 @@ To Enter USB Boot mode for the K1, hold the boot button, while holding boot hold
BIG caveat, I haven't gotten keyboard input to work through serial, I can only see the uboot logs. Please reach out if you figure out how to get keyboard input over serial for uboot.
## Unbricking Creality K1 Mainboard
## Unbricking Creality K1 Mainboard (USE AT YOUR OWN RISK)
The Creality K1 comes with a set of backup partitions. The OTA partition stores either the string `ota:kernel` or `ota:kernel2` to indicate which set of partitions to boot. This tool allows you to quickly switch between the two. This should fix a bricked Creality K1 mainboard given the backup partitions are functional. For cases where the partition table, main, and backup partitions are corrupted, read through this [guide](https://github.com/ballaswag/k1-discovery/blob/main/k1-ingenic-cloner-instruction.pdf) for a better chance of recoverying the mainboad.
```
@@ -27,6 +27,45 @@ Switched OTA to ota:kernel
```
## Dumping Partitions
Use this to dump your existing partitions in the K1. Example K1 partition table.
```
uboot(gpt/uboot): Offset 0x000000000, Length 0x0000100000
ota: Offset 0x000100000, Length 0x0000100000
sn_mac: Offset 0x000200000, Length 0x0000100000
rtos: Offset 0x000300000, Length 0x0000400000
rtos2: Offset 0x000700000, Length 0x0000400000
kernel: Offset 0x000b00000, Length 0x0000800000
kernel2: Offset 0x001300000, Length 0x0000800000
rootfs: Offset 0x001b00000, Length 0x0012c00000
rootfs2: Offset 0x014700000, Length 0x0012c00000
rootfs_data: Offset 0x027300000, Length 0x0006400000
userdata: Offset 0x02d700000, Length 0x01a4a00000
Total disk size:0x00000001d2104200, sectors:0x0000000000e90821
```
```
## start uboot
$ sudo ./usbboot --uboot
## dump the kernel partition to file ./kernel.out
$ sudo ./usbboot -o 0x000b00000 -s 0x0000800000 --dump-partition ./kernel.out
dumping parition at offset 0xb00000, size 0x800000
25.00% completed (1.00MB/s)
50.00% completed (1.00MB/s)
75.00% completed (1.00MB/s)
100.00% completed (1.00MB/s)
## dump the rootfs partition to ./rootfs.out
$ sudo ./usbboot -o 0x001b00000 -s 0x0012c00000 --dump-partition ./rootfs.out
dumping parition at offset 0x1b00000, size 0x12c00000
0.67% completed (0.67MB/s)
1.33% completed (1.00MB/s)
2.00% completed (1.00MB/s)
...
```
## SPL/u-boot
The general idea is to write and execute loader codes at different memory spaces during the different stages of boot. SPL is a smaller piece of code that lives in TCSM/SRAM and executed to initialize DRAM. Then the bigger uboot code can be loaded and executed from DRAM.