Add CMake build support Helps with our multi-distro story, makes the Debian and OE builds easier. The old Makefile has non-standard cross-compilation assumptions. CMake handles this is a standard way. It also makes our install target, clean target, handles pretty printing with optional verbosity, and much more all using the expected standards[0]. Add CMake support and remove the old Makefile to avoid confusion. [0] https://cmake.org/cmake/help/book/mastering-cmake/chapter/Why%20CMake.html Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Add install and uninstall targets Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Do not assume our cross compile target If one is using a cross compile then they should set CROSS_COMPILE. Having a default breaks native builds like done in Debian. Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Make dynamic linking the default Needing static linking is rare, it should not be the default. As it may still be useful for some, allow it set during build with a flag STATIC_BUILD=1. Add this to LDFLAGS as only the linker uses that. Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Do not use LDFLAGS when not linking Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Do not link against librt Most of librt has been merged with the standard lib, this linking is not needed now. Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Remove unused DESTDIR variable Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Add phony targets at target definition This helps make it easier to see which targets are phony and also helps us not forget any, like we did with all and clean. Signed-off-by: Andrew Davis <afd@ti.com>
makefile: Allow version to work with lightweight tags Currently only annotated tags are checked, leading to us still reporting v0.1 while we have v0.2 tagged. Fix this here. Signed-off-by: Andrew Davis <afd@ti.com>
soc: am62ax: add secure proxy descriptions Provide the secure proxy and communication path descriptions that are allowed for the AM62Ax SoC family Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: am62ax: add resource addignment descriptions The resource type IDs represent the resource ranges that are assignable to the AM62Ax's processing entities. Provide the board configuration resource assignment type IDs that are permitted in the AM62Ax SoC family Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: am62ax: add processors information The Processor IDs (not to be confused with Host IDs) represent the *actual* physical processors in the Am62Ax Provide the Processor IDs available in the AM62Ax SoC family Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: am62ax: add host description information These Host IDs represent processing entities for the AM62Ax. Typically a host is defined as a 'processing entity' which may be an actual processor or could represent a virtual machine. Provide the Host IDs permitted in the AM62Ax SoC family Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: am62ax: add device description information The Device IDs represent the SoC subsystems that can be modified by the DMSC TISCI message APIs. Some subsystems also use a Device ID as a parameter, allowing us to specify the management of a particular SoC subsystem. Provide the Device IDs permitted in the AM62Ax SoC family. Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: am62ax: add clock identifiers information The TISCI power management APIs use Device IDs and Clock IDs as parameters, allowing us granular control of the clocks for a particular subsystem. Define the Clock IDs that identify the incoming and outgoing clock signals for subsystems in the AM62Ax family of SoCs Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: j784s4: add secure proxy descriptions Provide the secure proxy and communication path descriptions that are allowed for the J784S4 Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: j784s4: add resource assignment descriptions The resource type IDs represent the resource ranges that are assignable to the J784S4's processing entities. Provide the board configuration resource assignment type IDs that are permitted in the J784S4 Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: j784s4: add processor information The Processor IDs (not to be confused with Host IDs) represent the *actual* physical processors in the J784S4 Provide the processor IDs available in the J784S4 Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: j784s4: add host description information These Host IDs represent processing entities for the J784S4. Typically a host is defined as a 'processing entity' which may be an actual processor or could even be a virtual machine Provide the Host IDs that are permitted in the J784S4 Signed-off-by: Bryan Brattlof <bb@ti.com>
soc: j784s4: add device description information The Device IDs represent SoC subsystems that can be modified via the DMSC TISCI message APIs. Some subsystems define a Device ID as a parameter, allowing us to specify the management of a particular SoC subsystem Provide the Device IDs that are permitted in the J784S4 Signed-off-by: Bryan Brattlof <bb@ti.com>