Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
Solra Bizna

[MC1.7.10][OC1.5.x]ARM Architecture "OC-ARM" (alpha, updated 2016-06-07)

Recommended Posts

After I added -addrinfocmd, I never tested without it. Apparently the simulator has never functioned without it.

I've made a new release of the simulator, 0.0a3a, that no longer has this bug.

It was working, it just spammed that alot, I didn't notice anything bad happening because of it. I got my code working to print a few x's on the screen and got your lua bootloader working. I didn't use -addrinfocmd as I am using windows and I only have arm-none-eabi on my raspberry pi which I build the roms on. anyway, good to see your still active :)

Link to post
Share on other sites

Is there any way to sleep until a signal is pushed? Atm I am using this:

#define pullSignal(buffer) asm volatile(\
	"1:\n\t"			\
	"STC p3, c0, %0\n\t"	\
	"BVS 1b \n\t"		\
	::"m"(buffer))

to wait for a signal but when I do that the emulator starts using 70% of my cpu while running. I tried using "MRC p3, 0, r0, cr2, cr0" like you do in the tetris but that gives same amount of lag.

 

Also would it be easy to link libc so I can use strcmp and such? I tried linking the compiled objects in newlib but it gives the error

arm-none-eabi-ld: error: ../newlib-jarm-build/libc/string/lib_a-strcmp.o uses VFP register arguments, bin/test.elf does not
arm-none-eabi-ld: failed to merge target specific data of file ../newlib-jarm-build/libc/string/lib_a-strcmp.o

would it work if I downloaded the GNU libc source code and compiled it with the same clang arguments?

Link to post
Share on other sites

Is there any way to sleep until a signal is pushed? Atm I am using this:

#define pullSignal(buffer) asm volatile(\
	"1:\n\t"			\
	"STC p3, c0, %0\n\t"	\
	"BVS 1b \n\t"		\
	::"m"(buffer))
to wait for a signal but when I do that the emulator starts using 70% of my cpu while running. I tried using "MRC p3, 0, r0, cr2, cr0" like you do in the tetris but that gives same amount of lag.
The lag (if you're talking about the latency between causing a signal and having the program "receive" it) is a side effect of the way OpenComputers syncs with Minecraft. The simulator is simulating it accurately(ish). Doing a tight loop to wait for a signal will reduce the lag in the simulator but will increase it in Minecraft.

 

Also would it be easy to link libc so I can use strcmp and such? I tried linking the compiled objects in newlib but it gives the error

arm-none-eabi-ld: error: ../newlib-jarm-build/libc/string/lib_a-strcmp.o uses VFP register arguments, bin/test.elf does not
arm-none-eabi-ld: failed to merge target specific data of file ../newlib-jarm-build/libc/string/lib_a-strcmp.o
would it work if I downloaded the GNU libc source code and compiled it with the same clang arguments?
Getting GNU libc compiled for this target would probably not work at all, and then use too much memory if it did. The Lua source code theoretically shows the proper way to link with the compiled newlib, but I haven't released it yet (because it's still broken and I'm lazy).

Here are some snippets that should get you on the right track getting newlib working:

cd newlib-jarm-build
../newlib-2.4.0/newlib/configure --target arm-none-eabi --disable-multilib --disable-newlib-register-fini --disable-newlib-mb --disable-newlib-wide-orient --enable-lite-exit --disable-newlib-iconv --disable-newlib-supplied-syscalls --prefix=`pwd` CC="clang" CFLAGS="-g -target armv7a-eabi -march=armv7-a -mfloat-abi=hard -mbig-endian -mhard-float -mfpu=vfpv4 -mhwdiv=thumb,arm -ccc-gcc-name arm-none-eabi-gcc"
make -k
# this will error, THIS IS NORMAL
Flags to compile with:

ASFLAGS=-march=armv7-a -mfloat-abi=hard -mfpu=vfpv4 -EB -meabi=5
TARGET_FLAGS=-target armv7a-eabi -mbig-endian -mfloat-abi=hard -mhard-float -mfpu=vfpv4 -mhwdiv=thumb,arm -D__ELF__
CFLAGS=$(TARGET_FLAGS) -Oz -g -nostdlibinc -isystem include/ -isystem ../newlib-jarm-build/ -isystem ../newlib-2.4.0/newlib/libc/include/ -Wall -Werror
LDFLAGS=--be8 -z max-page-size=4 -nostdlib -L../newlib-jarm-build -L../jarmrt/lib --no-enum-size-warning
LIBS=-lm -lc -lbuiltin
ARFLAGS=rs
You'll need to write some stubs... here's sbrk:

#include <unistd.h>
#include <errno.h>

extern uintptr_t ram_bytes;
extern unsigned char __heap_start;

void* sbrk(ptrdiff_t increment) {
  static uint8_t* cur_heap_end = ((uint8_t*)&__heap_start);
  if((uintptr_t)(cur_heap_end + increment) > ram_bytes) {
    errno = ENOMEM;
    return (void*)-1;
  }
  else {
    void* ret = cur_heap_end;
    cur_heap_end += increment;
    return ret;
  }
}
gettimeofday plugged into real time:

#include <sys/time.h>

int gettimeofday(struct timeval* tv, void* tz) {
  long long millis;
  asm("MRRC p3, 0, %0, %H0, cr1":"=r"(millis);
  tv->tv_sec = millis / 1000;
  tv->tv_usec = (millis % 1000) * 1000;
  return 0;
}
I can't remember whether I released jarmrt. I think I didn't yet because I hadn't sorted out license issues; it's an incredible hack that includes huge chunks of compiler-rt verbatim.
Link to post
Share on other sites

I see that occross can build the compiler for OC-ARM Little-Endian too. Does the mod actually support switching endianness and Little-Endian binaries?
I have a project that I simply cannot get to compile as Big-Endian, as I cannot figure out which linker script stays still armel after reconfiguring everything I found as armeb

Link to post
Share on other sites
On 2/23/2017 at 9:40 AM, feherneoh said:

I see that occross can build the compiler for OC-ARM Little-Endian too. Does the mod actually support switching endianness and Little-Endian binaries?
I have a project that I simply cannot get to compile as Big-Endian, as I cannot figure out which linker script stays still armel after reconfiguring everything I found as armeb

Sure does. Just two things to keep in mind:

  • The CPU boots in big-endian mode, so you'll want to do SETEND LE as your first instruction. I'm not certain, but it might switch to big-endian mode on interrupts as well. (Not that it matters, since my interrupt code is just stubs...)
  • boot0 will only load big-endian ELFs. It should be (relatively) simple to make a little endian version: do SETEND LE as the first instruction, manually byte swap the constants/shifts wherever boot0 uses a 32-bit integer comparison to test 4 bytes of memory, and remove the code that checks for the BE8 flag.

I'd planned to modify boot0 to be able to load either little- or big-endian ELFs, and switch the endianness itself. Of course, I'd also planned to make it OETF-compliant, and to finish the mod in general. If only I still had the time...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.