[LinuxBIOS] patch: extending LAR, and removing elf from linuxbios (it is not needed)

ron minnich rminnich at gmail.com
Tue Aug 28 17:26:44 CEST 2007

On 8/28/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [070828 01:54]:
> > What about creating directories for each payload so we can differentiate
> > between multiple payloads (in the original sense)?
> Yes, I would prefer something like that, too


> > Maybe we should introduce a major/minor version in the LAR header? Or a
> > different magic string for each revision?
> I generally hate versions. Think features, not numbers. But since this
> is probably not doable without significant overhead, I'd just go with a
> normal version header that gets increased every time we change the
> format. No need for major, minor, subminor, ...

but then you have to handle the versioning, and figure out what to do
if it does not match, and .... Let's not do this.

> > >     void *start;
> > >     int len;
> > >     u32 reallen;
> > > +   void * entry;
> > > +   void * loadaddress;
> >
> > void *entry;
> > void *loadaddress;
> Not sure how these pointers sneaked in here. They do break portability
> and cross compilability. Compiling LinuxBIOS on a 64bit host without
> compiling lar 32bit is not possible with such things in the header.

I think you guys have missed the point. These are in the mem_file
struct, and that struct is by definition a per-machine struct. There
is NO cross-compatibility issue with mem_file -- see include/lar.h.
mem_file is not even defined in util/lar/lar.h. The lar utility
doesn't know what it is.

> What was that linker auto rename trick that Marc mentioned recently?

The naming is not the issue. The issue is getting gcc to do abs calls,
not relative calls, for some symbols.

> Let's do this instead:
> INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/PICOBJ/initram.o
> and have a rule that handles all PICOBJ objects differently?

As long as you agree to write it, I don't know how :-)

Or why not just PICFLAGS for pic objects?

New patch attached with new payload naming. But I am not changing the
void * you mentioned, because I don't think it's a problem (there was
already another void * in the mem_file struct before I got there!)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: noelf3.diff
Type: text/x-patch
Size: 19726 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070828/e3fb7b5b/attachment.diff>

More information about the coreboot mailing list