can you tell me why objdump does not correctly disassemble the firmware for the C-SKY (ck803s) processor? what is .long: between the lines, unknown instructions? or am I setting the parameters for objdump incorrectly? here are mine: ./objdump -D -b binary -m csky:cs803 -EL firmware.bin
from off. sources use CK803S processor
this is how the bootloader works
The firmware is launched from the specified address at offset 0x04, look at the dump merged from the flash drive
objdump output
The whole problem is that all versions of objdump and even llvm-objdump incorrectly disassemble 32-bit instructions of C-SKY processors, I managed to find a working objdump version 2.27 on the website https://www.xrvm.cn/ there is also an Eclipse-based IDE
You've asked multiple questions. I don't know that version of objdump enough to comment on whether its a bug or missing option.
However, I can explain how the 32-bit instructions work.
The c-sky instruction stream is a series of 16-bit words. If bits 15 and 14 of the instruction word are NOT both 1s then it's a 16-bit instruction. However, if bits 15 and 14 of the instruction word are both 1s then it's a 32-bit instruction with the low 16-bits of the instruction in the following word.
Consider a hypothetical instruction with hex coding C1234567.
This will be stored as two 16-bit words C123 and 4567 in that order
In a big-endian environment, this will be stored as the following bytes -
C1 23 45 67 In a little-endian environment, this will be stored as the following bytes -
23 C1 67 45 In your firmware above the instruction at 3001000 is correct but the following instruction at 3001002 is actually C0016420
03001000: 112c lrw r1, 0x80000100 03001002: c0016420 mtcr r1, cr<0,0> Writing to control registers is very plausible in boot/init code.
The later 32-bit instruction with .long in the objdump output also seem to make sense.
