10 Apr, 2015
1 commit
-
This is important to have entry point in the beginning of .text section
because it allows simple loading and execution of U-Boot.For example pre-bootloader loads U-Boot in memory starting from offset
0x81000000 and then just jumps to the same address.Otherwise pre-bootloader would need to find-out where entry-point is. In
its turn if it deals with binary image of U-Boot there's no way for
pre-bootloader to get required value.Signed-off-by: Alexey Brodkin
03 Apr, 2015
3 commits
-
Intention behind this work was elimination of as much assembly-written
code as it is possible.In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.Signed-off-by: Alexey Brodkin
Cc: Simon Glass -
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.Signed-off-by: Alexey Brodkin
-
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.Still IVTs are implemented differently so we're keeping them in separate
files.Signed-off-by: Alexey Brodkin
09 Feb, 2015
1 commit
-
This way we may have very limited set of functions implemented so we
save some space.Also it allows us to build U-Boot for any ARC core with the same one
toolchain because we don't rely on pre-built libgcc.For example:
* we may use little-endian toolchain but build U-Boot for ether
endianess
* we may use non-multilibbed uClibc toolchain but build U-Boot for
whatever ARC CPU flavour that current GCC supportsPrivate libgcc built from generic C implementation contributes only 144
bytes to .text section so we don't see significant degradation of size:
--->8---
$ arc-linux-size u-boot.libgcc-prebuilt
text data bss dec hex filename
222217 24912 214820 461949 70c7d u-boot.libgcc-prebuilt$ arc-linux-size u-boot.libgcc-private
text data bss dec hex filename
222361 24912 214820 462093 70d0d u-boot.libgcc-private
--->8---Also I don't notice visible performance degradation compared to
pre-built libgcc (where at least "*div*" functions are had-written in
assembly) on typical operations of downloading 10Mb uImage over TFTP and
bootm.Signed-off-by: Alexey Brodkin
16 Jan, 2015
1 commit
-
"reset.c" and "cpu.c" have no architecture-specific code at all.
Others are applicable to either ARC CPU.This change is a preparation to submission of ARCv2 architecture port.
Even though ARCv1 and ARCv2 ISAs are not binary compatible most of
built-in modules still have the same programming model - AUX registers
are mapped in the same addresses and hold the same data (new featues
extend existing ones).So only low-level assembly code (start-up, interrupt handlers) is left
as CPU(actually ISA)-specific. This significantyl simplifies maintenance
of multiple CPUs/ISAs.Signed-off-by: Alexey Brodkin
Signed-off-by: Igor Guryanov
07 Feb, 2014
1 commit
-
These are library functions used by ARC700 architecture.
Signed-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: Francois Bedard
Cc: Wolfgang Denk
Cc: Heiko Schocher