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

[rougeminner 0]

jarom i think . in boot0.rom it says that its requires arm.elf to run. so i downloaded it from you files. somewhere.

 

 

GOT IT(ish) i did some screwing around with the files and its either a problem with it attempting to run C or the boot loader (boot0.rom) loading or running the file. i will keep screwing around to see if i can figure out how to fix it

[Solra Bizna 10]

Most of the .elf files in that archive are just produced as an intermediate step toward making a .rom file, and won't work as an "arm.elf" file. Use "test.elf" (built from the jarmrom folder) to test boot0.rom and your build process. Once that's working, the best way to proceed involves getting "lua.elf" (built from the luarom folder) to stop crashing (the bug is in the malloc implementation somewhere).

[GreaseMonkey 7]

Once that's working, the best way to proceed involves getting "lua.elf" (built from the luarom folder) to stop crashing (the bug is in the malloc implementation somewhere).

What libc are you using? You can just use newlib.

TIP: sbrk() returns the value of the break before it was called. Here, have a completely free* implementation:

 

#include <stdint.h>

extern char end;
void *current_break = (void *)&end;
void *sbrk(intptr_t increment)
{
  void *ret = current_break;
  current_break += increment;
  return ret;
}

*it's also completely untested. but hey, it's free!

EDIT: I had a look at your code, it appears you've rolled your own malloc(). TIP: Use the memory allocator that newlib provides in its libc. Then you only have to write sbrk().

[rougeminner 0]

i must be missing a file i didn't see a luarom. let me go get it 

 

found it. i feel stupid now i didn't have that folder 

[rougeminner 0]

in the past has anyone gotten it to boot into test.elf? because if any of you have i would really like to know, thats where i have been sitting for quite a while now. can't assess the damage until i have seen it. so once i get boot0.rom to work i will move to the C problem that greaseMonkey provided. but i can't even get it to boot test.elf. i have to rename it to arm.elf to get it to run but that fixes nothing really same error (i think, its a really generic error message)

[Solra Bizna 10]

What libc are you using? You can just use newlib.

TIP: sbrk() returns the value of the break before it was called. Here, have a completely free* implementation:

 

#include <stdint.h>

extern char end;
void *current_break = (void *)&end;
void *sbrk(intptr_t increment)
{
  void *ret = current_break;
  current_break += increment;
  return ret;
}

*it's also completely untested. but hey, it's free!

EDIT: I had a look at your code, it appears you've rolled your own malloc(). TIP: Use the memory allocator that newlib provides in its libc. Then you only have to write sbrk().

I initially rolled my own malloc, as well as the subset of the C library that Lua uses, in order to keep the size of the ROM down. Borrowing newlib's malloc implementation to replace my broken one is probably a good way to proceed.

in the past has anyone gotten it to boot into test.elf? because if any of you have i would really like to know, thats where i have been sitting for quite a while now. can't assess the damage until i have seen it. so once i get boot0.rom to work i will move to the C problem that greaseMonkey provided. but i can't even get it to boot test.elf. i have to rename it to arm.elf to get it to run but that fixes nothing really same error (i think, its a really generic error message)

There are a number of debug-related settings in the configuration file (OpenComputers-ARM.cfg in .minecraft/config). Enabling them may help you get more information.

[rougeminner 0]

Yup found it last night error on CPU.execute. I am going to take a look at it today once my laptop charges, so I need to replace some of the malloc code with what was listed above as well?

 

so i have gather a bit of a detail report and found that its a java error not a problem with the code in the game. here are some details

Open Computers WARN: Architecture runThreaded thew an error. THIS SHOULD NEVER HAPPEN 
java.lang.StackOverflowError 

at name.bizna.jarm.CPU.executeARMPage67(CPU.java:1390) ~[CPU.class:?] --here is the code at this location: int register_list = iword & 65535;

at name.bizna.jarm.CPU.executeARM(CPU.java:1456) ~[CPU.class:?] --I couldnt find the specific spot it was referencing as 1456 is a comment and after that is a int declaration but the error is happening early on in executeARM

at name.bizna.jarm.CPU.executeARM(CPU.java:399) ~[CPU.class:?] --Here is the code at this location:try { iword = vm.readInt(pc, true, false); }

at name.bizna.jarm.cpu.execute(CPU.java:382) ~[CPU.class:?] --Here is the code at this location:return cycleBudget <= 0;

at name.bizna.jarm.cpu.execute(CPU.java:345) ~[CPU.class:?] --Here is the code at this location:if(waitingForInterrupt && (haveIRQ() || haveFIQ())) waitingForInterrupt = false;

at name.bizna.jarm.cpu.execite(CPU.java:363) ~[CPU.class:?] --Here is the code at this location: generateDataAbortException(); --This code is in the catch for Alignment exception.

Now after all that reading i think i know what my problem is. i think i haven't set the CPU class as the code clearly says. that last error on line 363 repeats probably 300 times before it stops the computer. so i guess i need to find out how to set the type of CPU right?

[rougeminner 0]

And how would one go about setting the CPU Type

[Solra Bizna 10]

Now after all that reading i think i know what my problem is. i think i haven't set the CPU class as the code clearly says. that last error on line 363 repeats probably 300 times before it stops the computer. so i guess i need to find out how to set the type of CPU right?

Actually, the error is not related to that at all. The error is a StackOverflowError, which usually results from code calling itself out of control.

There have been several major changes to the source code since the last build I released. Those stacktraces won't match the latest code unless you've built my mod from source.

Here, in case you don't feel like wasting hours getting Gradle working, is the most recent build I made: http://mcjarm.tejat.net/0.0a2/OpenComputers-ARM-MC1.7.10-0.0a2.jar

Note that all previously-released ROMs and programs will not work with this build, because I changed the coprocessor number used to communicate with OpenComputers*. You'll have to build a new boot0.rom, test.elf, etc. from the source code I released.

Fortunately, the community revival effort (such as it is) might be unnecessary. Things had been improving psychologically to the point that I was working on getting a programming job. That was taking my free time, right up until I got hit by a car. I'm no longer mobile enough to fly out for the mandatory on-site interview, and a few days ago I found out that's not going to change for at least a few months. So until then, I have all this productive energy and not a lot of outlets for it... When I get home in a few days, I hope to pick up this mod again. Cross your fingers.

*I originally used CP0, but it really confused objdump because it insisted that CP0 instructions belonged to a specific Intel coprocessor, so it mangled things. CP3 doesn't get mangled, so I switched to that.

[tim4242 1]

Well getting hit by a car sucks (I speak from experience (been hit twice in four month (drivers in Germany are terrible (there are too many "()()()()")))) but it isn't irrevertable damage so that's good and it's also good you are getting back into this I hope it works and wish you good luck with your recovery.

[rougeminner 0]

Sorry to hear about the car, i hope its hurting more then you are . i am glad to hear that you are doing better, i was just about to have a mental break down trying to get all of these programs running on my mac. i have been stalled for 3 months trying to get this mod to load boot0.rom. and now i know why i haven't been getting anywhere. i feel some kinda stupid. for future reference, i have the means to write the code (assembler not java). but i do not have the means to compile (again assembler not java) them, also one more quick question, if i am reading correctly (i am 99.9% sure i am ) you have written boot0.rom in the ARM instruction set, but there are a few commands that i don't recognize and couldnt find documentation on, such as LDCMI, and LDCNE, etc are these specific commands to this mod or a specific arm processor. like i said above i couldnt find docs on them anywhere.

 

get well soon, and i can't wait for you to get back into this project.

 

btw, i have been flying by the seat of my pants, i have just been trying to do stuff until someone who new more then me could take over again, i literally just started learning the IS for ARM, so i am going to stop "working" and start figuring out WTH i am doing. boot loaders are a bit out of my knowledge right now. but hopefully i can figure the arm ones out soon

[Solra Bizna 10]

Well getting hit by a car sucks (I speak from experience (been hit twice in four month (drivers in Germany are terrible (there are too many "()()()()")))) but it isn't irrevertable damage so that's good and it's also good you are getting back into this I hope it works and wish you good luck with your recovery.

Jeez. Getting hit once sucks enough. Hope you don't continue the pattern...

 

Sorry to hear about the car, i hope its hurting more then you are .

I did tear a couple pieces off the car on my way down. I actually think that fight was a draw overall.

 

i am glad to hear that you are doing better, i was just about to have a mental break down trying to get all of these programs running on my mac. i have been stalled for 3 months trying to get this mod to load boot0.rom. and now i know why i haven't been getting anywhere. i feel some kinda stupid.

Don't get too discouraged. You've been working without a safety net, and doing pretty well so far.

If you're on a Mac, you're in luck, because you can get most of the tools you need just by installing XCode. That'll include GNU Make (which I use as my build system because I'm OOOOOLD(?)) and Clang (which is the best compiler to use). That'll also give you everything you need to build and install GNU Binutils from source code, with something like:

cd wherever/you/unpacked/binutils-gdb
./configure --target=arm-linux
make
sudo make install

Then you should have everything you need to build the source I posted. (Other than the Java source, that is.)

 

for future reference, i have the means to write the code (assembler not java). but i do not have the means to compile (again assembler not java) them, also one more quick question, if i am reading correctly (i am 99.9% sure i am ) you have written boot0.rom in the ARM instruction set, but there are a few commands that i don't recognize and couldnt find documentation on, such as LDCMI, and LDCNE, etc are these specific commands to this mod or a specific arm processor. like i said above i couldnt find docs on them anywhere.

 

get well soon, and i can't wait for you to get back into this project.

On ARM, when not operating in Thumb mode, every instruction includes a "condition code" that gives the conditions it should execute under. In the normal case, the condition is an implied "always". Both of those instructions are LDC instructions, with conditions; the first can be read as "LDC, but only if the result was negative (condition MI)" and the second as "LDC, but only if the result was unequal/non-zero (condition NE)". If I remember correctly, everywhere I used LDC with a condition was to load the "crash register"... which raises an OpenComputers error and shuts the computer off. A "crash with error message X if the thing didn't work" kind of thing.

 

btw, i have been flying by the seat of my pants, i have just been trying to do stuff until someone who new more then me could take over again, i literally just started learning the IS for ARM, so i am going to stop "working" and start figuring out WTH i am doing. boot loaders are a bit out of my knowledge right now. but hopefully i can figure the arm ones out soon

One of my hopes for this project is to give people like you a non-mental-breakdown-inducing path for experimentation and learning with a real ISA. It'll be a lot more fun when you no longer have to mess with broken bootloaders and buggy emulators and the like, (I hope. )

[rougeminner 0]

i am looking forward to when that happens solra. thats why i was (still am ) helping. i didn't know that all of that came with Xcode. i know nasm does, thanks for the tip. if Clang comes with Xcode i will use it. i had it installed at one point. but then it got removed don't know why. glad to hear that the car is hurting more

 

 

PS TELL THE CRAZY LUNATICS BEHIND THE GERMAN AND WHERE EVER SOLRA IS AT THAT THEY NEED TO STOP DRIVING!

[rougeminner 0]

ok. so i found bin utils. now i am having a small problem getting the arguments right. do you remember what you did with them originally and what does # mean. i thought it was like x86 where its a comment but i don't think it is anymore.

 

 

also. just so i can look over to try and figure out some more stuff you could release the source code for the new alpha? your code is really great to look through well commented almost no need for documentation. i wish everyone else coded like that

[Solra Bizna 10]

ok. so i found bin utils. now i am having a small problem getting the arguments right. do you remember what you did with them originally and what does # mean. i thought it was like x86 where its a comment but i don't think it is anymore.

I used commands like the ones I gave you to build and install binutils. When it's installed, all you have to do is change to the approprite JARM source code directory and "make". If the # you're seeing is in ARM assembly code, the # means "this exact value, as a constant". Without a #, it is taken as a register number instead. It has the same meaning in (at least) PowerPC, 68k, and 6502 assembly.

 

also. just so i can look over to try and figure out some more stuff you could release the source code for the new alpha? your code is really great to look through well commented almost no need for documentation. i wish everyone else coded like that

The source code that I released is the latest source code. I'm glad that the comments are helpful, they were a lot of work.

One of the reasons I didn't want to start releasing source code until it was closer to finished was that I wasn't completely happy with the comments and code organization that was already there. I was (and now, possibly, am) going to improve it as I went back and replaced placeholders with final code.

Speaking of possibly continuing, while there are a couple other projects competing for my time, this one is very dear to me. I'm back at my apartment now, but getting to my desktop (which, unlike my laptop, can run Minecraft without having an aneurysm) is still very difficult. That should only get better with time.

[rougeminner 0]

YEAH, glad your doing better and back at your place. thanks for the info. when i was asking about the arg's i should've been more specific. i was wondering the args for clang to compile the elf file. i understand that rom files are made with make. if i am correct. what i am trying to do at this point is experiment trying to make the boot loader. so  thats why i am wondering about these. the method is clang = elf and make = rom correct?

[Solra Bizna 10]

"make" builds everything. Just change to a directory containing a Makefile and run "make". Make is a tool where you tell it what commands are necessary to build things and it automatically builds them for you. Included with the source is a Makefile which tells Make how to use Clang, GNU LD, etc. to go from source code to ROM/ELF.

[rougeminner 0]

Grrrrr. just as i thought this would be a flawless install. i see what you where saying about binutils working with everything in an earlier post. gotta start figuring out whats wrong with it now. how ever i do feel really stupid for not putting together that the Makefile goes with guess what MAKE hahahahaha. i am stupid

 

 

some of the instructions i read up on i look at and go "No way he uses this in the code." and then i look for it can't find it so i skip reading it. then i go back day later and BOOM right in the middle of my screen is the command i didn't feel like learning. guess i should maybe stop skipping them. huh

[Solra Bizna 10]

guess i should maybe stop skipping them. huh

Don't worry. No matter how many commands you learn, the rabbit hole always goes deeper...

[rougeminner 0]

ok, i know that my constant coming back and asking for help has to be getting annoying. at least it is when people do it to me. but i am having a problem with binutils SURPRISE. you even told me i would have problems with this. but i was unable to find documentation to help me fix this. and i have been trying to fi it for the better part of a week. i will of course post the error below. the problem starts in my terminal, i think it is because of a faulty install of binutils. but that maybe why i couldn't find documentation of the error, it may not be a binutils error. but i have no clue i am giving up and passing on the problem anyone have an idea how to fix this?

//NOTE: This takes place in Mac OS X Ei Captain Terminal
 
gnumake 
Compiling src/test.c...
In file included from src/test.c:2:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include/inttypes.h:26:
In file included from /usr/include/inttypes.h:223:
/usr/include/sys/cdefs.h:707:2: error: Unsupported architecture
#error Unsupported architecture
 ^
In file included from src/test.c:2:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include/inttypes.h:26:
In file included from /usr/include/inttypes.h:226:
In file included from /usr/include/_types.h:27:
In file included from /usr/include/sys/_types.h:33:
/usr/include/machine/_types.h:34:2: error: architecture not supported
#error architecture not supported
 ^
In file included from src/test.c:2:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include/inttypes.h:26:
In file included from /usr/include/inttypes.h:226:
In file included from /usr/include/_types.h:27:
/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
typedef __int64_t       __darwin_blkcnt_t;      /* total blocks */
        ^
/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'
typedef __int32_t       __darwin_blksize_t;     /* preferred block size */
        ^
/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'
typedef __int32_t       __darwin_dev_t;         /* dev_t */
        ^
/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'
typedef __uint32_t      __darwin_gid_t;         /* [???] process and group IDs */
        ^
/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'
typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/
        ^
/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'
typedef __uint64_t      __darwin_ino64_t;       /* [???] Used for 64 bit inodes */
        ^
/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
        ^
/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'
typedef __uint16_t      __darwin_mode_t;        /* [???] Some file attributes */
        ^
/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'
typedef __int64_t       __darwin_off_t;         /* [???] Used for file sizes */
        ^
/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'
typedef __int32_t       __darwin_pid_t;         /* [???] process and group IDs */
        ^
/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'
typedef __uint32_t      __darwin_sigset_t;      /* [???] signal set */
        ^
/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'
typedef __int32_t       __darwin_suseconds_t;   /* [???] microseconds */
        ^
/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'
typedef __uint32_t      __darwin_uid_t;         /* [???] user IDs */
        ^
/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'
typedef __uint32_t      __darwin_useconds_t;    /* [???] microseconds */
        ^
In file included from src/test.c:2:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include/inttypes.h:26:
In file included from /usr/include/inttypes.h:227:
/usr/include/sys/_types/_wchar_t.h:33:9: error: unknown type name '__darwin_wchar_t'
typedef __darwin_wchar_t wchar_t;
        ^
17 errors generated.
gnumake: *** [obj/test.o] Error 1

when i am launching this program i am trying to make in the jarmrom folder. maybe i am doing something wrong?

[rougeminner 0]

so i was doing some asking around, people can't wait for this add-on to be finished and released functional. so when you release the Mod Solra i don't think one would worry about a user base. also i still haven't figured out the above question. if someone could PLEASE assist me with that i would be very grateful. if you see the problem starts with Architecture not supported then it escalates but from what you said in the past if i just install binutils and run make it should work right? 

[Solra Bizna 10]

Sorry, I missed your earlier post.

That's actually a problem with my code. It looks like I was assuming that the system's <inttypes.h> would have support for the ARM platform. That was silly of me. I appear to make that assumption with a few other headers as well, like <stdarg.h>.

This is fixable, but it is not an easy fix. It would be eaiser, instead, to get VirtualBox and install some flavor of Linux in a virtual machine, and use that virtual machine to build. I use Debian Linux myself, but Ubuntu Linux is more commonly used.

[rougeminner 0]

i have a copy of ubuntu on my desktop. thanks for the suggestion. so the problem with compiling was that i was that i wasn't using linux. will make note of that. also YEAH FOR FLU TYPE B!!!! don't you just love being bed written for 5 days. i sure don't but i am 

 

also. do you know any tricks for getting virtual box so simulate ARM?

[Solra Bizna 10]

i have a copy of ubuntu on my desktop. thanks for the suggestion. so the problem with compiling was that i was that i wasn't using linux. will make note of that.

Actually, the problem is that I set up my headers lazily. I'm being more careful with this Lua porting attempt, and future code from me will avoid that problem.

 

also YEAH FOR FLU TYPE B!!!! don't you just love being bed written for 5 days. i sure don't but i am

I know the feeling. I'm still mostly stuck in bed from the ankle fractures. On the one hand, I'm stuck for months... but on the other hand, I don't have all those pesky flu-like symptoms to make me miserable...

 

also. do you know any tricks for getting virtual box so simulate ARM?

VirtualBox can only virtualize x86 and AMD64 architectures. If you want an ARM simulator, look into QEMU... it won't do much good for OpenComputers ARM stuff, since it doesn't simulate the OpenComputers hardware, but it'd give you a way to actually run some ARM code.

Speaking of which, I've decided to make a simple QEMU-like simulator for the OpenComputers ARM machine. It'll make software testing much easier...

I spent a day getting newlib to actually build for OC-ARM, fighting literally every GNU tool used in the process except the assembler. Thanks to GreaseMonkey for pointing me toward newlib. It looks like it (barely!) is small enough to serve. (It'll probably get much better once I actually add Thumb support to JARM...)

Edit: It's going well. Attached a screenshot.

[Solra Bizna 10]

If you're interested in compiling programs for this on an Ubuntu or Debian Linux machine, you can save a lot of time and effort by installing the "gcc-arm-none-eabi" package. No need to compile binutils from source, and as an added bonus, my Makefiles won't need to be modified.

The simulator now has every intended feature except for touch and unmanaged drives. It simulates an OpenComputers computer with the following components:

• Tier 3 OC-ARM CPU
• (Optional) GPU of any tier, with matching screen and attached keyboard
• Any amount of RAM from 0 bytes to 2GiB
• EEPROM (not as a "component", only the low level parts, but including the SRAM/NVRAM)
• Arbitrary number of filesystems, read-only or read-write (without usage limits)

It simulates well enough to play RAMless Tetris, and boot programs, but there are some caveats in the emulation. In particular, it's excessively intolerant of incorrect component invocations. It's intended to allow testing of bootloaders and OSes rather than as an accurately-emulated OpenComputers system outside Minecraft.

I attached a screenshot of my Lua port running in the simulator. After nearly a year, I've finally hit another unimplemented instruction. Next stop: the emulator core. Hooray!

When I get Lua fully working, I'll make an a3 release, including the simulator and a bunch of source code. In particular, the simulator's (hideous) source code can be modified to simulate other architectures with relatively little work.