Can not figure out, why there is no dtb file under arch/arm/boot/dts/
dtc -O dtb -O test.dtb test.dts debian device tree compiler works
scripts/dtc/dtc -O dtb -O test.dtb test.dts kernel device tree
compiler works too
make dtbs runs without error, but there is no dtb file present
The output is as follows:
user1#vm:~/linux$ make dtbs
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK scripts/mod/devicetable-offsets.h
I am missing an output like:
DTC arch/arm/boot/dts/test.dtb
Kernel 4.14, armv7, target: sc573x-ezkit.
Any guesses?
Related
Does anyone know why the LD programe search a folder for the link script different to the one assigned in makefile in case 1? But in case 2 (link script file locates in the same folder as makefile), it works fine.
Below are the details of case 1 and case 2. Thanks for your help.
Case 1:
=====
makefile:
# Define linker script file here
LDSCRIPT= $(STARTUPLD)/STM32MP157CAAX_RAM.ld
(script file locates in the a different folder of "makefile")
output:
arm-none-eabi-g++ -o Debug/STM32MP157C-DK2.elf #"./Debug/objects.list" -mcpu=cor
tex-m4 -mthumb -DSTM32MP157Cxx --specs=nano.specs -mfloat-abi=hard -mfpu=fpv4-s
p-d16 -Wl,-Map=./Debug/STM32MP157C-DK2.map,-T"D:/Code/iot-plat/Firmware/Hardwar
es/BSP/startup/ARMCMx/GCC/ld/STM32MP157CAAX_RAM.ld" -Wl,--gc-sections -static -W
l,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,-cref,-u,Reset_Handle
r,--defsym=__process_stack_size__=0x400,--defsym=__main_stack_size__=0x400
c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-
none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot open linker script
file D;C:\Program Files\Git\Code\iot-plat\Firmware\Hardwares\BSP\startup\ARMCMx
\GCC\ld\STM32MP157CAAX_RAM.ld: Invalid argument
collect2.exe: error: ld returned 1 exit status
make: *** [D:/Code/iot-plat/Firmware/Hardwares/BSP/startup/ARMCMx/GCC/mk/rules.m
k:255: Debug/STM32MP157C-DK2.elf] Error 1
Case 2:
=====
makefile:
LDSCRIPT= STM32MP157CAAX_RAM.ld
(script file locates in the same folder of "makefile")
output:
arm-none-eabi-g++ -o Debug/STM32MP157C-DK2.elf #"./Debug/objects.list" -mcpu=cor
tex-m4 -mthumb -DSTM32MP157Cxx --specs=nano.specs -mfloat-abi=hard -mfpu=fpv4-s
p-d16 -Wl,-Map=./Debug/STM32MP157C-DK2.map,-T"STM32MP157CAAX_RAM.ld" -Wl,--gc-s
ections -static -Wl,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,-cr
ef,-u,Reset_Handler,--defsym=__process_stack_size__=0x400,--defsym=__main_stack_
size__=0x400
compile and link successfully...
I have a problem with linking files in order to get my Operating System (Thunder) to work. I compile start.o with:
nasm -f aout start.o start.asm
When I link the bootloader and kernel together it gives me this error:
start.o: File not recognised:file format not recognised.
Any suggestions on why I'm getting this error and how I can fix it?
The error you are getting suggests that LD doesn't understand the file format of start.o and can't process it as an object file. When I ran file start.o on your object it gave me this output:
start.o: Linux/i386 impure executable (OMAGIC)
You are using Cygwin on Windows. You say you used this line to assemble start.asm to start.o:
nasm -f aout start.o start.asm
The Cygwin linker (LD) doesn't understand the aout format as a valid object file format. What you can do is have NASM output a Microsoft Win32 (i386) object file by using the -fwin32 parameter. LD should be able to use that object file format during the linking stage.
Any body knows of a good tutorial on using the GNU blackfin toolchain with eclipse on Windows?
I'm trying to start with developing bare metal application on blackfin and I've installed the toolchain and eclipse C/C++ Juno but I'm unable to compile. Currently I'm getting the make: *** No rule to make target 'all' error but there are many other things I find myself lost at.
Many thanks in advance,
Hasan.
Edit: I've read a bit about the "make" programme, and decided to start a single-file test project to learn the command line toolchain (without the eclipse environment). Here is my main.c and associated makeFile:
//main.c
#include <stdio.h>
int main(void)
{
volatile int x = 42;
printf("%i\n", x);
return 0;
}
#makeFile
CPU = bf533-any
CROSS_COMPILE = bfin-elf-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)gcc
CFLAGS = -c -Wall
bfin_test: main.o
$(LD) main.o -mcpu=$(CPU) -o $#
main.o: main.c
$(CC) $(CFLAGS) main.c -mcpu=$(CPU) -o $#
Here is the result of running the make command on the cmd console:
D:\work\experiments\bfin_test_project>dir
Volume in drive D is Data
Volume Serial Number is 248D-2C8D
Directory of D:\work\experiments\bfin_test_project
14/04/2013 12:30 <DIR> .
14/04/2013 12:30 <DIR> ..
11/04/2013 13:30 102 main.c
14/04/2013 12:29 257 makeFile
14/04/2013 12:29 264 makeFile~
3 File(s) 623 bytes
2 Dir(s) 634,582,650,880 bytes free
D:\work\experiments\bfin_test_project>make
bfin-elf-gcc -c -Wall main.c -mcpu=bf533-any -o main.o
bfin-elf-gcc main.o -mcpu=bf533-any -o bfin_test
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-closer.o): In function `close
_r':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/clos
er.c:53: warning: _close is not implemented and will always fail
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-fstatr.o): In function `fstat
_r':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/fsta
tr.c:62: warning: _fstat is not implemented and will always fail
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-isattyr.o): In function `isat
ty_r':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/isat
tyr.c:58: warning: _isatty is not implemented and will always fail
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-lseekr.o): In function `lseek
_r':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/lsee
kr.c:58: warning: _lseek is not implemented and will always fail
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-readr.o): In function `read_r
':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/read
r.c:58: warning: _read is not implemented and will always fail
c:/program files (x86)/analog devices/gnu toolchain/2012r2/elf/bin/../lib/gcc/bf
in-elf/4.3.5/../../../../bfin-elf/lib\libc.a(lib_a-writer.o): In function `write
_r':
/usr/src/packages/BUILD/blackfin-toolchain-2012R2/gcc-4.3/newlib/libc/reent/writ
er.c:58: warning: _write is not implemented and will always fail
This produced the .o and (supposedly) the elf file. And here is the result of trying to run the elf file using the toolchain simulator:
D:\work\experiments\bfin_test_project>bfin-elf-run bfin_test
program stopped with signal 11 (Segmentation fault).
According to http://docs.blackfin.uclinux.org/doku.php?id=toolchain:sim, this should be running the simulator in the virtual mode. (Not sure if I should be providing other files)
Also I'm not sure if the output file (bfin_test) is actually an elf file or if it can be run using the simulator (bfin-elf-run). But if so, I'm wondering why am I getting a segmentation fault of such a seemingly simple programme. Any idea anybody? Note that I get the same error when changing main to contain only "return 0;".
Could someone please tell me where I'm going wrong.
Thanks again,
Hasan,
Take a look at these links. They might offer some help.
https://docs.blackfin.uclinux.org/doku.php?id=toolchain:bare_metal:compile
https://docs.blackfin.uclinux.org/doku.php?id=toolchain:bare_metal:link
It is a real struggle getting the GNU toolchain flowing for Blackfin but once you do its works pretty well.
Jim
I have two files -> fact.h and main.c in the /home/snyp1/new folder. main.c has the main function which calls the fact(int x) function in fact.h. I am creating a .a archive with the ar command ->
snyp1#Snyp:~/new$ ar -r -s libfact.a fact.o
ar: creating libfact.a
fact.h fact.o libfact.a main.c
snyp1#Snyp:~/new$ gcc main.c -L/home/snyp1/new -lfact -o main
/home/snyp1/new/libfact.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
snyp1#Snyp:~/new$ ranlib libfact.a
snyp1#Snyp:~/new$ gcc main.c -L/home/snyp1/new -lfact -o main
/home/snyp1/new/libfact.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
I am on ubuntu 12.04. Please let me know whats wrong. (Also, if I don't use the -L/.../new, gcc will say it can't find "lfact", maybe its because its not in /usr/local/lib)
EDIT: OK I have found the cause. Its due to the fact that I was using fact.h to build the fact.o and then putting it in the library, it wasn't working as expected. So I now changed it into file.c and is working fine now. I should have provided that information, I'm sorry. Though I don't know why this kind of problem should arise. Aren't libraries possible to make without at least one .c file in it?
I was using fact.h to build the fact.o and then putting it in the library, it wasn't working as expected.
Do you mean you were compiling fact.h to produce fact.o?
If so, that wasn't doing what you expect. When you invoke gcc on a header file it produces a precompiled header, not an object file. So although you got a file called foo.o it wasn't a valid object file. If you had just run gcc -c fact.h it would have produced a precompiled header fact.gch, but presumably you ran gcc -c fact.h -o fact.o which causes the file to be called fact.o even though it's still a precompiled header. file fact.o would have shown that:
$ file fact.o
fact.o: GCC precompiled header (version 013) for C
You could have forced GCC to treat the file as C code, not a header, by running gcc -x c -c fact.h -o fact.o (the -x c says to treat the input as C code instead of inferring the type from the file extension) but it's probably simpler and less confusing to just name your file correctly instead of trying to compile a header.
Aren't libraries possible to make without at least one .c file in it?
They need at least one object file (i.e. .o file) but you didn't have a valid object, you had a precompiled header misleadingly named as .o, but it was not actually an object file.
if I don't use the -L/.../new, gcc will say it can't find "lfact", maybe its because its not in /usr/local/lib
The linker doesn't only look in /usr/local/lib, there are other default places it looks, but yes, that's basically the problem. Note that you can also say -L. if the library is in the current directory, that's easier than giving an absolute path.
I'm not sure ar supports a dash on anything other than the first option. Try
ar -rs libfact.a fact.o
or just
ar rs libfact.a fact.o
Mind you, I don't know why running ranlib didn't work though.
I'm trying to run a basic assembly file using 64 Bit Mac OS X Lion, using nasm and ld which are installed by default with Xcode.
I've written an assembly file, which prints a character, and I got it to build using nasm.
nasm -f elf -o program.o main.asm
However, when I go to link it with ld, it fails with quite a few errors/warnings:
ld -o program program.o
ld: warning: -arch not specified
ld: warning: -macosx_version_min not specificed, assuming 10.7
ld: warning: ignoring file program.o, file was built for unsupported file format which is not the architecture being linked (x86_64)
ld: warning: symbol dyld_stub_binder not found, normally in libSystem.dylib
ld: entry point (start) undefined. Usually in crt1.o for inferred architecture x86_64
So, I tried to rectify a few of these issues, and got nowhere.
Here's one of things I've tried:
ld -arch i386 -e _start -o program program.o
Which I thought would work, but I was wrong.
How do you make the object file a compatible architecture that nasm and ld will agree with?
Also, how would you define the entry point in the program (right now I'm using global _start in .section text, which is above _start, which doesn't seem to do much good.)
I'm a bit confused as to how you would successfully link an object file to a binary file using ld, and I think I'm just missing some code (or argument to nasm or ld) that will make them agree.
Any help appreciated.
You need to use global start and start:, no underscore. Also, you should not be using elf as the arch. Here is a bash script I use to assemble my x86-64 NASM programs on Mac OS X:
#!/bin/bash
if [[ -n "$1" && -f "$1" ]]; then
filename="$1"
base="${filename%%.*}"
ext="${filename##*.}"
nasm -f macho64 -Ox "$filename" \
&& ld -macosx_version_min 10.7 "${base}.o" -o "$base"
fi
If you have a file called foo.s, this script will first run
nasm -f macho64 -Ox foo.s
Which will create foo.o. The -Ox flag makes NASM do some extra optimization with jumps (i.e. making them short, near or far) so that you don't have to do it yourself. I'm using x86-64, so my code is 64-bit, but it looks like you're trying to assemble 32-bit. In that case, you would use -f macho32. See nasm -hf for a list of valid output formats.
Now, the object file will be linked:
ld -macosx_version_min 10.7 foo.o -o foo
I've set the -macosx_version_min option to quiet NASM down and prevent a warning. You don't have to set it to Lion (10.7). This will create an executable called foo. With any luck, typing ./foo and hitting return should run your program.
In regard to the ld: warning: symbol dyld_stub_binder not found, normally in libSystem.dylib warning, I get that every time too and I'm not sure why, but everything seems fine when I run the executable.
OK, looking at your samples I assume you either used a generic nasm or linux assembly tutorial.
The first thing you need to take care of is the binary format created by nasm.
Your post states:
ld: warning: ignoring file program.o, file was built for unsupported file format which is not the architecture being linked (x86_64)
Thats the result of the '-f elf' parameter which tells nasm you want a 32bit ELF object (which would be the case for e.g. linux). But since you're on OSX what you want is a Mach-O object.
Try the following:
nasm -f macho64 -o program.o main.asm
gcc -o program program.o
Or if you wan't to create a 32bit binary:
nasm -f macho32 -o program.o main.asm
gcc -m32 -o program program.o
Regarding the _start symbol - if you wan't to create a simple program that will be able
to use the provided libc system functions then you shouldn't use _start at al.
It's the default entry point ld will look for and normaly it's provided in your libc / libsystem.
I suggest you try to replace the _start in your code by something like '_main'
and link it like the example above states.
A generic libc-based assembly template for nasm could look like this:
;---------------------------------------------------
.section text
;---------------------------------------------------
use32 ; use64 if you create 64bit code
global _main ; export the symbol so ld can find it
_main:
push ebp
mov ebp, esp ; create a basic stack frame
[your code here]
pop ebp ; restore original stack
mov eax, 0 ; store the return code for main in eax
ret ; exit the program
In addition to this I should mention that any call's you do on OSX need to use an aligned stack frame or your code will just crash.
There are some good tutorials on that out there too - try searching for OSX assembly guide.
It's probably easier just to let gcc do the heavy lifting for you, rather than trying to drive ld directly, e.g.
$ gcc -m32 program.o -o program
The mac gcc compiler won't link elf objects. You need a cross compiler...
http://crossgcc.rts-software.org/doku.php?id=compiling_for_linux
Then you can proceed with something similar to this...
/usr/local/gcc-4.8.1-for-linux32/bin/i586-pc-linux-ld -m elf_i386 -T link.ld -o kernel kasm.o kc.o