• Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
Welcome to OpenComputers

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more!

This message will be removed once you have signed in.

  • Announcements

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

      The latest released version of OpenComputers is version 1.6.1 for MC 1.7.10, 1.8.9, 1.9.4 & 1.10.2. See more information here! Beta/Dev builds can be found at the Jenkins Build Server (ci.cil.li)
Solra Bizna

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

136 posts in this topic

This post contains instructions on how to make a .elf, requiring boot0 to load it. The procedure for making a .rom instead is nearly identical, but unless you really want to be limited to 1000ish instructions, you should probably make a .elf instead.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

Active might be pushing it. Alive, maybe. :)

It would not have been completely broken; the exceptions would, however, have prevented some important updating and left the simulator subtly broken. (Unless I don't know how Java's `finally` keyword works, which is entirely possible.)

Share this post


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?

Share this post


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.

Share this post


Link to post
Share on other sites

I'm picking up this project again in earnest. I've determined that the main thing that's been gumming me up is trying to attack the software and hardware ends simultaneously and in an ad-hoc way. To that end, I'm going to focus down.

I've edited the OP with my current todo list.

Share this post


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

Share this post


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...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now