Solra Bizna

EEPROMs do not currently have a means of targeting a specific architecture. All of the OC-ARM EEPROMs I've made have had the following structure: --[==[actual program data goes in here]==]error"This EEPROM is not compatible with Lua computers" My ROM mapping code "skips" any --[ followed by zero or more = followed by another [ in the EEPROM. This solution avoids the problem of loading an OC-ARM EEPROM in a Lua computer, but not any other combination. It also takes away 65 bytes that could otherwise be used by the program.I think we need a more general strategy for architecture-specific ROMs

test.elf requires the "allowSerialDebugCP" option in OpenComputers-ARM.cfg to be set. Otherwise, all the CP7 instructions are undefined, and test.elf will immediately crash. Just by continuously trying stuff, and learning from when the stuff didn't work. After a while, stuff started working more often than not working.

For whatever reason, your test.elf is not getting the EF_ARM_HASENTRY flag set. This is weird. It's correctly marked as big-endian---that error message does not indicate that it's not big-endian, but that it is unusable for whatever reason. (Not being big-endian would be one such reason.) I don't know why EF_ARM_HASENTRY is not being set, because the entry point field in the header is being set. I'll have to do more research into this; for now, you can modify your boot0 to not care about that flag by changing line 149 of boot0.s from: LDR r1, =0x00800002 to: LDR r1, =0x008

If you look at tetris.rom in a text editor (or put it into a Lua computer) you'll see that it's actually also a valid Lua BIOS, which throws an error saying something like "this EEPROM is not compatible with the Lua architecture". The Makefile uses the "echo" command to assemble that. It passes the "-n" flag to echo, to say "don't add a newline to the end of your output". Your Make (possibly because it was BSD Make and not GNU Make?) was interpreting it as something to echo, rather than a command line flag.

If it's glitching even with other architectures, something else is going on. As for the extra 8 bytes... something is going wrong involving the echo command. Edit the makefile again, replacing both occurrences of "@echo -n" with "@/bin/echo -n", then do "make clean" and "make". If it works, tetris.rom will be 4093 bytes, and will work.

I only need the .rom file.

Can you upload your tetris.rom somewhere? I would like to examine the differences between yours and mine.

That shouldn't happen. What other mods are on the server? And have you tried tetris.rom?

I've always used my own servers, whether the fancy online one or the not-so-fancy UNIX-machine-that-happens-to-be-on-the-same-network one. I'm too old to use Dropbox.

Add -meabi=5 to the ASFLAGS line, then do "make clean" and try "make" again. That should, finally, fix it. Or cause a different error. We'll see...

That was intended to replace, specifically, the "-Iinclude/" part of the line, and not the entire line.

Yes, you mis-edited the Makefile. When you edited the CFLAGS to build against newlib, you removed some other important options. As for getting binutils on your Mac... it makes sense that --disable-werror would fix it. If I'd known about that option, I might've suggested it. You should be able to get it building on your Mac now.

Well, the only thing I can think of now is another edit to CFLAGS in the makefile. After "-target armv7a-eabi" add "-march=armv7-a". If that doesn't work, then I'm not sure how to proceed.

That's probably the ld, as, etc. that came with XCode. Not the ones you just built. If that's an error, and not a warning, then it will completely prevent the build/install from finishing. The errors with newlib didn't stop it from working because you passed the "-k" option to make, which says "make as much as you can in spite of errors"; this works for newlib because the errored part isn't needed for OC-ARM, but won't work for binutils. That should be recent enough. But it's clang's built-in assembler that's rejecting my inline assembly. Looking closer at your error, it's a

The "make install" step is actually not necessary if you modify the jarmrom makefile to point to the compiled tools in-tree. In fact, it might do more harm than good by getting in the way of the native tools. I'm not sure. You'll need to replace every arm-none-eabi-<tool> with the path to the compiled tool, whether in-tree or where it gets installed by "make install", either way. I'm not sure how that version number maps to mainline clang; my clang is reasonably recent, and reports its version as 3.5. Since a lot of ARM assembly related stuff was added/improved 3.5, I suspect earlier

What version of clang are you running? "clang --version" will let you find out. Also, since you're on your Mac again, you'll have to modify the makefile slightly. Only the first few lines. Those tell it where to find the appropriate versions of those utilities. You should change the ones that say "arm-none-eabi-<tool>" to whatever the full path to the <tool> binary is. For example, mine would be: AS=/home/sbizna/nobackup/binutils-gdb/gas/as-new CC=clang CXX=clang++ LD=/home/sbizna/nobackup/binutils-gdb/ld/ld-new OBJCOPY=/home/sbizna/nobackup/binutils-gdb/binutils/objcopy OBJDUM

You have a space in one of the directory names in that path. That will cause problems with some older / poorly written tools. Putting quotes around `pwd` (to make "`pwd`") might fix the immediate problem, but run into another problem of the same type farther down. Try it and see. (If it works, I'll update my notes.)

What error message does it give? If you give me the config.log I can take a look at what's going on. (And again, if all you want to build is assembly programs like boot0, you don't need to get the C compiler part working at all.)

Hello World in x86 assembly is "simple" only when you can call out to the operating system to do simplified IO. There isn't an OS to speak of right now for OC-ARM, so a Hello World program has to:Initialize its own memory (only if it's a ROM rather than an ELF loaded by a bootloader) Get the address of a GPU Get the address of a screen Bind the GPU to the screen Set appropriate colors Call gpu:set(...) to display a message on the screen Sleep indefinitely, and/or handle raw signals For what it's worth, this job is much easier on OC-ARM than it would be on a typical microcontroller. OC-ARM's IO

boot0 is already a working, if spartan, bootloader. I wouldn't recommend a bootloader as a first project on an unfamiliar architecture.

Okay, then, until the next release here's what you can do. Pick a directory to put all of these things into. (For me, because I'm lazy and disorganized, it's my home directory.) Download the newlib source code and unpack it there. Make a new directory called "newlib-jarm-build" next to the "newlib-2.4.0" directory, change to it, and do: ../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"

Building the ROMs on an ARM machine should work. As an added bonus, you'll have a version of GDB that can make use of core dumps made by OC-ARM or its simulator. It's weird that it's picking up inttypes.h but not cdefs.h. Future releases from me won't suffer from this issue, because they'll use newlib's headers and ignore system ones. Until then, I think that problem can be fixed by installing the appropriate kernel headers package. (e.g. the linux-kernel-headers package on Debian or Ubuntu) If that doesn't work, I'll post instructions for building newlib and modifying my Makefiles to use

Not knowing ahead of time what the OETF is, it is not at all clear what that subforum is for. If that's the intended purpose, the description should be clarified.

That depends on which code you mean. You still need to compile whatever ROM and/or program you're running, but you won't have to start up Minecraft and get things copied over just to do basic testing. Also, I haven't posted the simulator yet, just a couple of screenshots. The simulator itself will be posted shortly after I finish the painstaking process of debugging every single floating point instruction used by Lua so I know which ones are breaking everything. (So close...) Move its cage outside, place treats inside the cage, and wait some distance from the cage. (Assuming this is a

You moved all the ones I know about. The current layout suits me. It might be necessary to create a separate "specs" section later if there's enough traffic.