Re: [LinuxBIOS] [v3][PATCH] have a static initram improvements.

[Stefan Reinauer]

This is a simple example how to statically link printk into initram.

It grows initram by incredible 2000 bytes here. So yes, this is a
solution for now.

Signed-off-by: Stefan Reinauer

Index: mainboard/emulation/qemu-x86/Makefile
===================================================================
--- mainboard/emulation/qemu-x86/Makefile	(revision 459)
+++ mainboard/emulation/qemu-x86/Makefile	(working copy)
@@ -39,11 +39,14 @@
 #

INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/initram.o
+INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/console.o
+INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/vtxprintf.o
+INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/uart8250.o

$(obj)/linuxbios.initram: $(obj)/stage0.init $(obj)/stage0.o $(INITRAM_OBJ)
    $(Q)# initram links against stage0
    $(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
-	$(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x80000 $(INITRAM_OBJ) \
+	$(Q)$(LD)  -Ttext 0x80000 $(INITRAM_OBJ) \
    	--entry=main -o $(obj)/linuxbios.initram.o
    $(Q)printf "  OBJCOPY $(subst $(shell pwd)/,,$(@))\n"
    $(Q)$(OBJCOPY) -O binary $(obj)/linuxbios.initram.o \

[LinuxBIOS] [v3][PATCH] have a static initram improvements.

[ron minnich]

Acked-by: Ronald G. Minnich

if you wish to commit. I think this is acceptable for the short term.

ron

On 7/19/07, Stefan Reinauer  wrote:
> This is a simple example how to statically link printk into initram.
>
> It grows initram by incredible 2000 bytes here. So yes, this is a
> solution for now.
>
> Signed-off-by: Stefan Reinauer
> Index: mainboard/emulation/qemu-x86/Makefile
>
> --- mainboard/emulation/qemu-x86/Makefile       (revision 459)
> +++ mainboard/emulation/qemu-x86/Makefile       (working copy)
> @@ -39,11 +39,14 @@
>  #
>
> INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/initram.o
> +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/console.o
> +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/vtxprintf.o
> +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/uart8250.o
>
> $(obj)/linuxbios.initram: $(obj)/stage0.init $(obj)/stage0.o $(INITRAM_OBJ)
>         $(Q)# initram links against stage0
>         $(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
>   $(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x80000 $(INITRAM_OBJ) \
>   $(Q)$(LD)  -Ttext 0x80000 $(INITRAM_OBJ) \
>           --entry=main -o $(obj)/linuxbios.initram.o
>   $(Q)printf "  OBJCOPY $(subst $(shell pwd)/,,$(@))\n"
>   $(Q)$(OBJCOPY) -O binary $(obj)/linuxbios.initram.o \

[LinuxBIOS] [v3][PATCH] have a static initram improvements.

[Stefan Reinauer]

* ron minnich  [070720 06:41]:
> Acked-by: Ronald G. Minnich
>
> if you wish to commit. I think this is acceptable for the short term.
>
> ron

I will work some more on this. I added the stuff for amd norwich, too,
yesterday. It required post_code, too. So I made an extra file
post_code.c (post_code was in stage1.c before)
> On 7/19/07, Stefan Reinauer  wrote:
> > This is a simple example how to statically link printk into initram.
> >
> > It grows initram by incredible 2000 bytes here. So yes, this is a
> > solution for now.
> >
> > Signed-off-by: Stefan Reinauer
> > Index: mainboard/emulation/qemu-x86/Makefile
> >
> > --- mainboard/emulation/qemu-x86/Makefile       (revision 459)
> > +++ mainboard/emulation/qemu-x86/Makefile       (working copy)
> > @@ -39,11 +39,14 @@
> >  #
> >
> > INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/initram.o
> > +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/console.o
> > +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/vtxprintf.o
> > +INITRAM_OBJ := $(INITRAM_OBJ) $(obj)/lib/uart8250.o
> >
> > $(obj)/linuxbios.initram: $(obj)/stage0.init $(obj)/stage0.o 
> > $(INITRAM_OBJ)
> >         $(Q)# initram links against stage0
> >         $(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
> >   $(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x80000 $(INITRAM_OBJ) \
> >   $(Q)$(LD)  -Ttext 0x80000 $(INITRAM_OBJ) \
> >           --entry=main -o $(obj)/linuxbios.initram.o
> >   $(Q)printf "  OBJCOPY $(subst $(shell pwd)/,,$(@))\n"
> >   $(Q)$(OBJCOPY) -O binary $(obj)/linuxbios.initram.o \

[LinuxBIOS] [v3][PATCH] have a static initram improvements.

[ron minnich]

Hey, btw, I realized a way to do the vector table that might work well
over time. I think I mentioned this before, but I'll mention it again.

Rather than have LB define the vector table in a mainboard-independent
way, which will get harder as we add more mainboards, have the
MAINBOARD code define its own vector table. That way, mainboards can
add/change vector table elements as needed and not affect any other
mainboard.

Then, one step further: create a LAR file that is the symbol table for
stage 0/1 that has been burned into FLASH. The mainboard has its
vector table, and this links against the symbols in the lar file. That
way, if you ONLY have a copy of the bios, and you need to create a new
stage 2, the path is open to linking against the stage0/1 in flash,
without requiring a rebuild of stage0/1.

Is this too crazy?

ron

[LinuxBIOS] have a static initram improvements.

[Jordan Crouse]

On 20/07/07 09:18 -0700, ron minnich wrote:
> Then, one step further: create a LAR file that is the symbol table for
> stage 0/1 that has been burned into FLASH. The mainboard has its
> vector table, and this links against the symbols in the lar file. That
> way, if you ONLY have a copy of the bios, and you need to create a new
> stage 2, the path is open to linking against the stage0/1 in flash,
> without requiring a rebuild of stage0/1.
>
> Is this too crazy?

Frankly?  Yes.  I'm not super excited about re-inventing the wheel here.
I would much rather play the linking script games then come up with
something new.  ld scripts are not evil, if they are done right.

Jordan

[LinuxBIOS] have a static initram improvements.

[ron minnich]

On 7/20/07, Jordan Crouse  wrote:
> On 20/07/07 09:18 -0700, ron minnich wrote:
> > Then, one step further: create a LAR file that is the symbol table for
> > stage 0/1 that has been burned into FLASH. The mainboard has its
> > vector table, and this links against the symbols in the lar file. That
> > way, if you ONLY have a copy of the bios, and you need to create a new
> > stage 2, the path is open to linking against the stage0/1 in flash,
> > without requiring a rebuild of stage0/1.
> >
> > Is this too crazy?
>
> Frankly?  Yes.  I'm not super excited about re-inventing the wheel here.
> I would much rather play the linking script games then come up with
> something new.  ld scripts are not evil, if they are done right.

ok, I had to ask :-)

ron

[LinuxBIOS] have a static initram improvements.

[Peter Stuge]

On Fri, Jul 20, 2007 at 10:27:59AM -0600, Jordan Crouse wrote:
> > create a LAR file that is the symbol table for stage 0/1 that
> > has been burned into FLASH.
>
> Frankly?  Yes.  I'm not super excited about re-inventing the wheel
> here.

Why put another symbol table in lar - it is a symbol table already.

post_code and friends could be lar files.

//Peter

[LinuxBIOS] [v3][PATCH] have a static initram improvements.

[Marc Jones]

Stefan Reinauer wrote:
> ron minnich  [070720 06:41]:
> > Acked-by: Ronald G. Minnich
> >
> > if you wish to commit. I think this is acceptable for the short term.
> >
> > ron
>
> I will work some more on this. I added the stuff for amd norwich, too,
> yesterday. It required post_code, too. So I made an extra file
> post_code.c (post_code was in stage1.c before)

post_code() should be a macro in post_code.h. It is small enough it 
should always be inline. Yes/No?

Marc

[LinuxBIOS] [v3][PATCH] have a static initram improvements.

[Peter Stuge]

On Fri, Jul 20, 2007 at 01:24:59PM -0600, Marc Jones wrote:
> > yesterday. It required post_code, too. So I made an extra file
> > post_code.c (post_code was in stage1.c before)
>
> post_code() should be a macro in post_code.h. It is small enough it
> should always be inline. Yes/No?

Not sure - it may not always just be one instruction.

inline void shold work as well as a macro no?

Either way, macro or function, we need to make sure all POST codes
come from a single piece of code.

//Peter