Don't use floadfile() for loading module data.  The SLZM header
contains both the compressed and uncompressed sizes, so we might as
well just use that information to know ahead of time how much memory
to allocate.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Use ELF compressed into a custom lzo container.  The reason for not
using the standard lzop container is that we are doing one-shot
decompression anyway, and by having the appropriate information in the
header we can manage memory better.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Meant to handle symbols exported from the core, but we just
pregenerate the dynamic section instead.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Always strip the modules; they are too big unstripped.  Specifically,
we generate unstripped *.elf files, and then convert them to
stripped *.c32 files.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Set the sonames of shared libraries to the filename, so we don't end
up with full pathnames embedded in the files.

Exclude in .gitignore

Signed-off-by: Gene Cumm <gene.cumm@gmail.com>

The location of __file_info[] and ansicon_counter are split between
the core and ldlinux.c32. We can end up calling __ansicon_close (from
fp->oop->close) in the process of reloading ldlinux.c32, and while
ansicon_counter is set to its initialised data value of 0 when
reloading ldlinux.c32, the core is never reloaded, and so
__file_info[] retains its pointers.

What this amounts to is that when ldlinux.c32 tries to call
openconsole() after being reloaded, the core tries to close the
ansicon device (the core still has pointers to __ansicon_close)
despite the ansicon code having no knowledge of ever being opened
(because ansicon_counter was reinitialised).

The most logical way to deal with this is to close stdin, stdout and
stderr when unloading ldlinux.c32.

It also turns out that sys/openconsole.o was present in two Makefile
variables which lead to duplication of code, data, etc. We only need
it present in libcom32min.a and not in the core since the core never
handles opening consoles, at least not now that we've deleted
printf_init() which is safe because we always open a console in
ldlinux.c32 anyway.

Signed-off-by: Matt Fleming <matt.fleming@intel.com>

There's no reason to use the COMBOOT API at all now that we can have
any undefined symbols resolved at runtime - we can just access
functions directly.

Signed-off-by: Matt Fleming <matt.fleming@intel.com>

The reason for this merge is that we need the fix to core/fs/cache.c
without which we can potentially dereference an invalid pointer.

The below conflict is a result of the new setup_data blob code being
merged from the master branch.

Conflicts:
	com32/lib/Makefile

Make it a generic setup_data loader keyed by type.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>