the Zynq FSBL - an "identity crisis"

I find calls to __libc_init_array() and __libc_fini_array() in the file xil-crt0.S These typically handle C++ constructors and destructors -- but we aren't dealing with C++ -- there is no C++ whatsoever in the FSBL sources (or anywhere in "embeddedsw". The xil-crt0.S file even calls exit() when and if main returns!!

I find calls to a number of linux system calls. Things like lseek(), open(), sbrk() and more. These might be called by the general C language crt0.S routine, but we should not be including that when we link our executable! Implementation os these routines are provided that are stubs returning EIO -- but they shouldn't be getting called in the first place!

I find ARM thumb code being referenced. I first noticed this when I was looking at the objdump disassembly of the original fsbl.elf while tracking down __libc_fini_array(). I see calls to routines at odd addresses, which triggers a transition to thumb. What seems to be happening is that all of the routines from libc (i.e. via -lc) are getting pulled in as thumb code. For whatever reason the library that is being used as libc is /usr/arm-none-eabi/lib/thumb/v7+fp/hard/libc.a -- and don't ask me how and why that choice is being used.

I think the whole idea of linking against some ill-determined libc is wrong from the very start for an embedded application. My intent is to find source for things like strlen() that are actually needed and avoid linking against any system library.

I find references to linux include files such as stdint.h, stddef.h, string.h, ctype.h, and linux/types.h -- it seems to work, but the FSBL source tree really ought to be self contained.

We even find floating point! Why does a boot loader need to be fooling with floating point registers? Well it doesn't. This is just another indicator that the source tree is generic and intended for purposes other that the FSBL. The offending code is in asm_vectors.S and is conditional on a paramter set in "bspconfig.h", called:

#define FPU_HARD_FLOAT_ABI_ENABLED 1

I have other questions about how things are done. For example I don't think it is right to be using gcc as a linker for an embedded application. The original build system goes through contortions to make it work, but using gcc to link would only be the right thing for an executable intended to run on the linux operations system. They shoe-horned it into working, but there are better ways.