Using Purdue Robotics Operating System with a Vex Cortex on OS X. Attempting to flash it with the included uniflash program, but it is throwing an error during the flash process. Here is the logs.
CC -I../include -I../src init.c
LN ./bin/auto.o ./bin/init.o ./bin/opcontrol.o ./firmware/libccos.a -lgcc -lm to bin/output.elf
text data bss dec hex filename
12108 0 3840 15948 3e4c ./bin/output.elf
arm-none-eabi-objcopy ./bin/output.elf -O binary ./bin/output.bin
UniFlash v0.7 by Stephen Carlson
Using serial port /dev/tty.usbmodem1411 (USB Serial)
Stopping user code... done.
Error: No response when requesting system info
Interrogating VEX system...
Judging by the output from your shell you are running PROS 1.6 or older which is now out of date as of September. Try upgrading to the latest version found here and see if the problem persists.
Related
I am learning the os tutorial.
https://github.com/cfenollosa/os-tutorial
After I using gcc convert my basic.c to basic.o,
gcc -ffreestanding -c basic.c -o basic.o
As describe in the toturial, I get a file named basic.o which is an object file.
According to the next step, I need to convert basic.o to basic.bin.
ld -o basic.bin -Ttext 0x0 --oformat binary basic.o
The question is that my platform is Macbook Pro(M1) which os version is 12.4.
It seems that there are differences between macos ld and windows ld.
If I input ld -o basic.bin -Ttext 0x0 --oformat binary basic.o, I will get feedback as below.
ld: unknown option: -Ttext
What command about ld I need to convert basic.o to basic.bin on my platform?
Yes they are different, in fact gcc will be just a symlink to clang unless explicitly installed and told otherwise.
As for the -T option, I'm not too sure if you know what it means(if you don't, it will basically tell the linker to put the text section at address 0x0).
You might want to invest the time and look for how to build a linkerScript because you will probably going to use that later anyway.
How to build a linkerScript
If the link is dead at some point, you can just google "linkerScript ld" and it will show some tutorials.
I am trying to compile librtmp so I can build FFmpeg with RTMP support for ARM processor.
I already have the toolchain, and solo build of FFmpeg was also successful, and testing from inside the ARM processor was success as well.
My understanding:
- Ffmpeg
-- Librtmp
--- Openssl
--- zlib
This hierarchy is required to build FFmepg.
So far I have built openssl for ARM, and zlib for ARM, and, I can see it is located in right ARM output folder.
Prerequisites:
export LD_LIBRARY_PATH=/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/lib/
export CCPREFIX="/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/bin/arm-unknown-linux-uclibcgnueabi-"
export CFLAGS="-I/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/include"
export LDFLAGS="-L/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/lib/"
1- Steps to build zlib:
export CC=arm-linux-gcc
./configure --prefix=/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr
make
make install
2- Steps to build openssl:
export cross=arm-linux-
./Configure dist --prefix=/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr
make CC="${cross}gcc" AR="${cross}ar r" RANLIB="${cross}ranlib"
make install
3- Steps to build librtmp:
make CROSS_COMPILE=arm-linux- INC=-I/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/include LIB=-L/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/lib
above 1,2 steps are successful, with 3rd, I get this:
make CROSS_COMPILE=arm-linux- INC=-I/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/include LIB=-L/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/lib
make[1]: Entering directory '/home/user/Downloads/ip_code/rtmpdump/librtmp'
arm-linux-gcc -shared -Wl,-soname,librtmp.so.1 -o librtmp.so.1 rtmp.o log.o amf.o hashswf.o parseurl.o -lssl -lcrypto -lz
/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.4.0/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: cannot find -lssl
/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.4.0/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: cannot find -lcrypto
/opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.4.0/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
Makefile:92: recipe for target 'librtmp.so.1' failed
make[1]: *** [librtmp.so.1] Error 1
make[1]: Leaving directory '/home/user/Downloads/ip_code/rtmpdump/librtmp'
Makefile:76: recipe for target 'librtmp/librtmp.a' failed
make: *** [librtmp/librtmp.a] Error 2
but in the output folder I can see the right files are there:
[user#localhost rtmpdump]$ cd /opt/toolchain_gnueabi-4.4.0_ARMv5TE/usr/lib
[user#localhost lib]$ ls
bin libavcodec.a libgmp.so.10.0.2 libz.so
certs libavdevice.a libiberty.a libz.so.1
engines libavfilter.a libmpfr.la libz.so.1.2.11
gcc libavformat.a libmpfr.so man
include libavutil.a libmpfr.so.4 misc
ldscripts libcrypto.a libmpfr.so.4.0.1 openssl.cnf
lib libfakeroot-0.so libpostproc.a pkgconfig
libaacplus.a libfakeroot.la libssl.a private
libaacplus.la libfakeroot.so libswresample.a share
libaacplus.so libgmp.la libswscale.a
libaacplus.so.2 libgmp.so libx264.a
libaacplus.so.2.0.2 libgmp.so.10 libz.a
[user#localhost lib]$
Any idea how to compile?
Thanks
Just for info: the rtmpdump is apparently a requirement for some other OS... I compiled FFmpeg without rtmpdump/librtmp yesterday, and in the 'enabled protocols' at time of ./configure , I could see RTMP/RTMPS etc. as well...
Very surprised, I ran the compiled FFmpeg on the targetted ARM device, and it runs without any issue: I guess support was already there inside ffmpeg (for ARM), while I was wrestling with rtmpdump.
Enabled protocols:
async httpproxy rtmpte
cache https rtmpts
concat icecast rtp
crypto md5 srtp
data mmsh subfile
ffrtmpcrypt mmst tcp
ffrtmphttp pipe tee
file prompeg tls_openssl
ftp rtmp udp
gopher rtmpe udplite
hls rtmps unix
http rtmpt
Issue resolved!
I'm trying a program about blender deformation. My laptop is amd64 and able to support i386.
faye#fish:/usr/bin$ dpkg --print-foreign-architectures
i386
faye#fish:/usr/bin$ dpkg --print-architecture
amd64
I have no much experience about makefile script. According to the google search info, I made two line code additions in the makefile.mk.
# -I option to help the compiler finding the headers
CFLAGS += $(addprefix -I, $(INCLUDE_PATH))
CC=gcc -m32
Here is the issue:
When I run any template OpenGL code with:
gcc test.c -lm -lpthread -lglut -lGL -lGLU -o test
It seems the code and the libs work correctly.
However, if I do the same to the makefile.mk(CC=gcc), it gives many errors in the following form:
/usr/bin/ld: i386 architecture of input file `../external/lib/libxxxxxxxx.a(xxxxxxxx.o)' is incompatible with i386:x86-64 output
if I use (CC = gcc -m32), the error will switch to:
/usr/bin/ld: cannot find -lglut
/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lGLU
I guess maybe there is something wrong in 64 bit os running 32 bit application and libs linking?
-m32, when used with a x86-64 compiler does not mean "compile this program for i386", but actually means "create a program for x86-64 CPUs using only instructions that operate on 32 bit registers".
What you have there is some binary that has been compiled for native i386 and now try to combine it with a program that's compile for x86-64 with just 32 bit registers. Those two don't fit together. The big question here of course is, why do you want to use those i386 binaries at all. There are some good reasons for using 32bit-x86-64 (half the size for pointers and which can massively reduce the memory bandwidth), but in general you want 64 bit binaries. So many problems of 32 bit memory management vanish by virtue of having vast amounts of address space.
Looks like extenal/lib is full of 32 bit precompiled archives. You could track each one down and recompile (or use shared libraries), but that'll be a massive PITA.
Just because your OS supports i386 doesn't mean you've got the libraries installed. In this case of that program, it's enough to install libc6-dev-i386 and freeglut3-dev:i386 packages.
PS: No need to edit anything. make CC='gcc -m32'
I am new in NDK and I am following this guide to build OpenSSL for Android, I am using Windows 7 and Cygwin for this.
I'm having errors when trying to build the OpenSSL library.
# From the 'root' directory
$ . ./setenv-android.sh
$ cd openssl-1.0.1g/
$ perl -pi -e 's/install: all install_docs install_sw/install: install_docs install_sw/g' Makefile.org
$ ./config shared no-ssl2 no-ssl3 no-comp no-hw no-engine --openssldir=/usr/local/ssl/$ANDROID_API
$ make depend
$ make all
When I try the make depend command I have 2 errors:
cryptlib.c:171:3: error: #error "Inconsistency between crypto.h and cryptlib.c"
# error "Inconsistency between crypto.h and cryptlib.c"
the cryplib.c line 171 says:
#if CRYPTO_NUM_LOCKS != 41
# error "Inconsistency between crypto.h and cryptlib.c"
#endif
I don't know how to fix that error.
the other one is uid.c:77:10: error: #include expects "FILENAME" or <FILENAME>
#include OPENSSL_UNISTD
if I change the line 77 in uid.c to #include <unistd.h> I get an error in the Makefile, so I don't know if it's the way to fix it, the error was in depend Makefile.
depend:
#[ -z "$(THIS)" -o -f buildinf.h ] || touch buildinf.h # fake buildinf.h if it does not exist
#[ -z "$(THIS)" ] || $(MAKEDEPEND) -- $(CFLAG) $(INCLUDE) $(DEPFLAG) -- $(PROGS) $(LIBSRC)
#[ -z "$(THIS)" -o -s buildinf.h ] || rm buildinf.h
#[ -z "$(THIS)" ] || (set -e; target=depend; $(RECURSIVE_MAKE) )
#if [ -z "$(THIS)" ]; then $(MAKE) -f $(TOP)/Makefile reflect THIS=$#; fi
Another question is if I can use this guide to build the OpenSSL library to the 64bit arch. (x86_64, arm64 and mips64) I haven't found information about OpenSSL for Android in those architectures, all post about it are old and those arch didn't exist for Android
EDIT
I found a way to solve partially my problem (not the best one but it works), the problem was due some errors in some paths, because I was trying to use Cywin on Windows and some files(I don't which ones) were trying to reach some paths that doesn't exist because I was on Windows and not in Linux, so I just install Ubuntu on a virtual machine and try this guide again, and I could compile libraries and I have libcrypto.a libcrypto.so libssl.a libssl.so for Android ARM, x86, mips, ARM64 and x86_64 Architectures.
But the libraries doesn't work for x86_64 and ARM64, when I try to compile a .c using the android.mk for x86_64 or arm64 eabi it doesn't compile due some compatibility errors, but if a try to compile de same .c file withe the "x86_64" or "arm-64" for a x86 or arm eabi it does compile, so they are still a 32bit libraries, this is not the answer because I need the libraries for all the architecture (at least for armv5, armv7, armv8-64, x86, x86_64), this is just a small step.
I will be updating to help someone with the same problem and if someone want to help me.
When I try the make depend command I have 2 errors:
cryptlib.c:171:3: error: #error "Inconsistency between crypto.h and cryptlib.c"
# error "Inconsistency between crypto.h and cryptlib.c"
There's a problem with the symlinks. Unpack the tarball again with tar zxvf. Then, verify the header files are not 0 length.
Also see Inconsistency between crypto.h and cryptlib.c on the OpenSSL mailing list. And How to copy symbolic link file from Linux to Windows and then back to Linux but still keeping it as a symbolic link on Stack Overflow.
Using this guide and modifying the file setenv-android.sh you can easy compile openssl for arm, x86 and mips.
You just have to modify _ANDROID_NDK _ANDROID_ARCH _ANDROID_EABI _ANDROID_API parameters
note: for mips you'll have to add some lines in the file around
around line 120:
arch-mips)
ANDROID_TOOLS="mipsel-linux-android-gcc mipsel-linux-android-ranlib mipsel-linux-android-ld"
;;
around line 200:
if [ "$_ANDROID_ARCH" == "arch-mips" ]; then
export MACHINE=mipsel
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=mips
export CROSS_COMPILE="mipsel-linux-android-"
fi
if you follow the guide you'll have libcrypto.a, libssl.a, libcrypto.so and libssl.so.
if you want the libraries for 64 bits architecture you can do a pull from a device using adb, all android device have libcrypto.so and libssl.so in /system/lib64 for 64bits version (only in a 64bits device), and /system/lib the 32bits version, you can use an emulator for that, if you can want the 64bits version of the static libraries (libcrypto.a and libssl.a) in this link you can find the way to do it.
I decided to write a simple asm bootloader and a c++ kernel. I read a lot of tutorials, but I cant compile an assembly file seems like this:
[BITS 32]
[global start]
[extern _k_main]
start:
call _k_main
cli
hlt
(I would like to call th k_main function from c file)
Compile/assemble/linking errors:
nasm -f bin -o kernelstart.asm -o kernelstart.bin:
error: bin file cannot contain external references
okay, then i tried create a .o file:
nasm -f aout -o kernelstart.asm -o kernelstart.o (That's right)
ld -i -e _main -Ttext 0x1000 kernel.o kernelstart.o main.o
error: File format not recognized
Someone give me plz a working example or say how to compile. :/
(I'm browsing the tutorials and helps 2 days ago but cannot find a right answer)
I don't have a direct answer on where your error comes from. However, I do see a lot of things going wrong so I'll write these here:
nasm
nasm -f aout -o kernelstart.asm -o kernelstart
Does that even work? That should be something like
nasm -f aout -o kernelstart kernelstart.asm
ld
ld -i -e _main -Ttext 0x1000 kernel.o kernelstart.o main.o
Since you said you wanted to make a bootloader and a kernel, I'm assuming your goal here is to make ld output something that can be put in the MBR. If that's the case, here are some things to keep in mind:
You didn't specify the output format. If you want to make an MBR image, add --oformat=binary to the command line options. This makes sure a flat binary file is generated.
You set the entry point to _main. I'm not sure where that symbol is defined, but I guess you want your entry point to be start because that's where you call your kernel.
You link your text section starting at 0x1000. If you want to put your image in the MBR to be loaded by the BIOS, it should be linked at 0x7c00.
As a side note: it seems your trying to link your bootloader and kernel together in one image. Just remember that the MBR is can only hold 512 bytes (well, actually 510 bytes since the last 2 should contain a magic value) so you won't be able to write much of a kernel there. What you should do is create a separate kernel image and load this from your bootloader.
I hope these points will help you in solving your problem.
Also, you'll find a lot of useful information as OSDev. Here is a tutorial on writing a real mode "kernel" that only uses the MBR. The tutorial contains working code.