Thanks Julius for the inputs. That makes sense. We already have a precedence for sharing headers between the cross compiler and the host toolchain for the host tools via `tools_share` directory. Similarly we can have a `xxx_share` directory in /include for these headers. I think it is worth factoring out the U() macro to this folder. Regarding the __ASSEMBLY__ and AARCH32/AARCH64 macros, we could split the header out for asm, aarch32, aarch64 variants of the file thus removing the need to define these macros.
I tried factoring them out into different headers and have them include each other at first, but it didn't really work out and became a huge mess because they're so interdependent. entry_point_info_t is an architecture-dependent type that depends on param_header_t (an architecture-independent type), and they both have assembly-only constants associated with them. So in the end you would have to include bl_common_raw.h, bl_common_asm_raw.h, aarch64/ep_info_raw.h, aarch64/ep_info_asm_raw.h, param_header_raw.h and param_header_asm_raw.h all independently based on what macros are set. Maybe if I only split them up by architecture but not by asm/non-asm, that could work better.
For the assembly, btw, another option would be to use the macro __ASSEMBLER__ instead of __ASSEMBLY__. That is predefined by GCC and most other compilers (according to https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html#Standard-... it's even part of a standard, although I can't find another source for that), so we could just assume that it will work in third-party projects as well and wouldn't need to do anything special for it. (If we want to do that, I think it would make sense to switch all TF-A code from __ASSEMBLY__ to __ASSEMBLER__ first. Do you know if there was a good reason you went with a custom-defined __ASSEMBLY__ in the first place?)
I think these raw header are worth grouping together as it makes it clear the need to handle them separately and makes it easier to export these headers. A strawman proposal for the header hierarchy :
/include/tf_share --> the ep_info, param_header and other such common header could go in there /include/tf_share/ bl_aux_params --> folder for the new bl_aux param header /include/tf_share/bl_aux_params/vendor/rockchip --> folder for vendor extensions for the rockchip platform
Does that sound sensible ?
Yes, that sounds good. I would maybe suggest using "plat" instead of "vendor" to mirror the way the toplevel directories are structured better, so <share/bl_aux_params/plat/rockchip/plat_params.h> or maybe just <share/plat/rockchip/plat_params.h> instead. But I'm happy to follow whatever naming you prefer.