Little-endian or1k in binutils is unavailable or severely broken.

[ilyakurdyukov]

In some files I found that theoretically binutils supports little-endian OpenRISC, but I can't get the assembler to compile in little-endian format, there's simply no such option for or1k!

I can ask objdump to disassemble in little-endian format, but then half the instructions are broken:

objdump -D -b binary -EB -m or1k test_be.bin

   0:	18 60 07 27 	l.movhi r3,0x727
   4:	a8 63 0e 00 	l.ori r3,r3,0xe00
   8:	9c 63 ff ff 	l.addi r3,r3,-1
   c:	bc 43 00 00 	l.sfgtui r3,0
  10:	13 ff ff fe 	l.bf 0x8
  14:	44 00 48 00 	l.jr r9

objdump -D -b binary -EL -m or1k test_le.bin

   0:	27 07 60 18 	*unknown*
   4:	00 0e 63 a8 	l.ori r3,r3,0xe00
   8:	ff ff 63 9c 	*unknown*
   c:	00 00 43 bc 	l.sfgtui r3,0
  10:	fe ff ff 13 	*unknown*
  14:	00 48 00 44 	l.jr r9

[stffrdhrn]

Sorry for the late late reply, we don't really track issues on this repo and binutils support is all upstream we try to use the upstream sourceware resources for tracking issues and requests. Or send an email to the openrisc mailing list linux-openrisc@vger.kernel.org.

Can you explain more your use case for little endian? I didn't know it was supported. What do you need, assembler, disassbler? what else? How did you create the test_le.bin?

See: https://sourceware.org/binutils/

[ilyakurdyukov]

While reverse engineering a Chinese camera, I found a Chinese chip with little-endian OpenRISC architecture. To get LE code, I compiled for BE and did bswap. The chip is AX3295B from AppoTech (aka BuildWin).

GCC has support for different endianess, but it is not connected properly for OpenRISС.

[stffrdhrn]

@ilyakurdyukov , understood, I will see what I can do to get this fixed. Do you remember if the chip had delay slots? I have heard of some chips out of china that also didn't have the standard OR1K delay slots.

The example code you posted doesn't seem to have delay slots. If so, perhaps it would be beneficial to start supporting the no-delay slot architectures as well.

[ilyakurdyukov]

The firmware does not use delay slots, but I think this is configurable via the ND bit of CPUCFGR.

[olofk]

I think that LE was never really supported. I have a vague memory of that some OpenRISC hardware, e.g. Allwinner's A20 SoC stores the code LE even though the CPU is BE. But it was a long time since I last looked at this.

[stffrdhrn]

I am looking at this now it seems the issue with related to dealing with certain immediates, i.e. l.bf -8 fails on LE, but l.bf 8 is ok.

I started to debug, I only had a few minutes:

The disassebler for OpenRISC objdump is in opcodes/or1k-dis.c with functions print_insn_or1k > default_print_insn > print_insn, this is machine generated from the CGEN machine definitions written in lisp. I can see that what we are passing to the backend is the proper instruction 0x18600727, but lookup seems to fail.

gdb session in print_insn

(gdb) n
363       insn_list = CGEN_DIS_LOOKUP_INSN (cd, (char *) buf, insn_value);
(gdb) n
364       while (insn_list != NULL)
(gdb) p insn_list
$6 = (const CGEN_INSN_LIST *) 0x0
(gdb) p/x insn_value
$7 = 0x18600727

[stffrdhrn]

OK, this patch seems to fix it, it was not the immediate, the opcode was not taken from the correct place when using little endian.

< shorne@antec ~/work/gnu-toolchain/binutils-gdb > git diff
diff --git a/cpu/or1k.opc b/cpu/or1k.opc
index 5d20a1f33a7..748187edcdf 100644
--- a/cpu/or1k.opc
+++ b/cpu/or1k.opc
@@ -38,7 +38,7 @@
 #undef  CGEN_DIS_HASH_SIZE
 #define CGEN_DIS_HASH_SIZE 256
 #undef  CGEN_DIS_HASH
-#define CGEN_DIS_HASH(buffer, value) (((unsigned char *) (buffer))[0] >> 2)
+#define CGEN_DIS_HASH(buffer, value) ((value >> 26) & 0xff)
 
 /* Check applicability of instructions against machines.  */
 #define CGEN_VALIDATE_INSN_SUPPORTED
diff --git a/opcodes/or1k-opc.h b/opcodes/or1k-opc.h
index d3d084b1bec..6eec8006828 100644
--- a/opcodes/or1k-opc.h
+++ b/opcodes/or1k-opc.h
@@ -35,7 +35,7 @@ extern "C" {
 #undef  CGEN_DIS_HASH_SIZE
 #define CGEN_DIS_HASH_SIZE 256
 #undef  CGEN_DIS_HASH
-#define CGEN_DIS_HASH(buffer, value) (((unsigned char *) (buffer))[0] >> 2)
+#define CGEN_DIS_HASH(buffer, value) ((value >> 26) & 0xff)
 
 /* Check applicability of instructions against machines.  */
 #define CGEN_VALIDATE_INSN_SUPPORTED

[stffrdhrn]

I posted a patch here: https://sourceware.org/pipermail/binutils/2025-June/141828.html

In terms of supporting little endian for gas, one workaround is to just use objcopy as you mentioned

I created a makefile as follows to help with my testing:

OBJCOPY := or1k-elf-objcopy
AS := or1k-elf-as

test_le.bin: test.o
        $(OBJCOPY)  test.o --reverse-bytes=4 -O binary test_le.bin
test.o: test.S
        $(AS) test.S -o test.o

[stffrdhrn]

I had a look we could add endianness to OpenRISC gas by modifying this function and adding an endianness option such as -mlittle-endian. There might be other things we need to consider too, but I don't think we really have the need for this now as we could use objcopy.

// from gas/config/tc-or1k.c
void
md_number_to_chars (char * buf, valueT val, int n)
{
  number_to_chars_bigendian (buf, val, n); 
}

I think I will leave this out for now if that is ok.