[LinuxBIOS] printk()/post_code(): Compile failure for all hardware targets in v3

[Carl-Daniel Hailfinger]

Hi,

I can't compile any of the hardware targets in v3. The qemu target
builds just fine.

Error for the AMD Norwich target:
In file included from LinuxBIOSv3/mainboard/amd/norwich/initram.c:24:
include/post_code.h:23: error: ‘post_code’ redeclared as different kind
of symbol
include/console.h:38: error: previous declaration of ‘post_code’ was here

Error for the Advanced Digital Logic MSM800SEV:
In file included from LinuxBIOSv3/mainboard/adl/msm800sev/initram.c:24:
include/post_code.h:23: error: ‘post_code’ redeclared as different kind
of symbol
include/console.h:38: error: previous declaration of ‘post_code’ was here

Error for the Artec Group DBE61:
In file included from LinuxBIOSv3/mainboard/artecgroup/dbe61/initram.c:24:
include/post_code.h:23: error: ‘post_code’ redeclared as different kind
of symbol
include/console.h:38: error: previous declaration of ‘post_code’ was here

The reason is similar for all of them:
include/console.h specifies
> void post_code(u8 value);

include/post_code.h specifies (because _SHARED is defined)
> void stage0_post_code(u8 value) ;
> void (*post_code)(u8 value) = stage0_post_code;

Of  course these definitions do conflict.

While I appreciate the idea to use one printk()/post_code()
implementation for all stages, it seems the current realization has a
few aspects which give us various interesting problems to solve:
* The conflicting post_code() definitions above are not alone, the same
happens for printk.
* If you remove post_code() from include/console.h everywhere
post_code() is shared, you encounter the next problem: If two files with
_SHARED are linked together, each of them will contain the assignment
(*post_code)=stage0_post_code, resulting in linker errors because a
symbol appears twice.
* Even if you manage to avoid all the problems above, a new problem
arises: We have to build a LAR archive in one continuous flow because we
can't extract the location of the stage0 symbols from an existing
bootblock in a LAR archive and thus can't link initram and stage2
against an existing bootblock. Because of that, we never can do partial
BIOS updates, which defeats the whole purpose of LAR.

Suggestions for solving the problems mentioned above:
* Always wrap shared function definitions in SHARED macros.
* Make sure the assignment "ret (*func)(args) attr= stage0_##func"
happens only once per final linked object.
* Include a .map file of shared stage0 functions in the LAR.

Regards,
Carl-Daniel