[LinuxBIOS] Re: VGA support

[Steven J. Magnani]

Yhlu writes:
> So at last for your linuxbios.rom, you should do 
> cat atix.rom linuxbios.rom > final_linuxbios.rom

I went through this exercise with my board last week, and this procedure
didn't work for me. Might be because there is nothing in the LB code
that prevents the memory range occupied by the video ROM from being
allocated to PCI devices.

What I finally ended up doing is creating a wrapper .S file for my
mainboard that pulls the video ROM into the compiled LB RAM image:

.section .rodata.optionrom
    .globl	_vgarom_start
_vgarom_start:
    .incbin
"../../../../../src/mainboard/intel/xe7501devkit/vga.rom"
    .globl	_vgarom_end
_vgarom_end:

In Config.lb I reference a symbol defined in the wrapper:

chip drivers/pci/onboard
        device pci 0.0 on end
            register "rom_address" = "_vgarom_start"
    end

...and in my mainboard chip.h I forward-declare the symbol, so static.c
can compile:

extern unsigned char _vgarom_start[];

This strategy has the advantage of making the rom address independent of
changes in the size of LinuxBIOS or the payload. The disadvantage is
that the video ROM gets compiled into both the fallback and normal LB
RAM images (it takes up twice as much flash space as it needs to).

I am wondering if it might be useful for LB to support some kind of
flash partition structure (similar to Redboot) to allow storage of
things common to both fallback and normal images, or to support user
selection among two or more payloads.

------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

#include <standard.disclaimer>

[yhlu]

That is good, but the atix.rom will be compiled into normal image and
fallback image.

Also for Fallback image, you will make linuxbios_ram.rom too big.
finally image could be greater than 128K for four way and 8 way
system.

Maybe we can think about one way to let fallback image use the
atix.rom in normal image.

then the problem comes again: some time we need flash normal image
only and keep fallback image for safe, So You need to make sure
atix.rom in the exact same position.

YH

On 8/11/05, Steven J. Magnani  wrote:
> Yhlu writes:
> > So at last for your linuxbios.rom, you should do
> > cat atix.rom linuxbios.rom > final_linuxbios.rom
>
> I went through this exercise with my board last week, and this procedure
> didn't work for me. Might be because there is nothing in the LB code
> that prevents the memory range occupied by the video ROM from being
> allocated to PCI devices.
>
> What I finally ended up doing is creating a wrapper .S file for my
> mainboard that pulls the video ROM into the compiled LB RAM image:
>    .section .rodata.optionrom
>    .globl  _vgarom_start
>
> _vgarom_start:
>        .incbin
> "../../../../../src/mainboard/intel/xe7501devkit/vga.rom"
>        .globl  _vgarom_end
> _vgarom_end:
>
> In Config.lb I reference a symbol defined in the wrapper:
>
> chip drivers/pci/onboard
>        device pci 0.0 on end
>            register "rom_address" = "_vgarom_start"
>    end
>
> ...and in my mainboard chip.h I forward-declare the symbol, so static.c
> can compile:
>
> extern unsigned char _vgarom_start[];
>
> This strategy has the advantage of making the rom address independent of
> changes in the size of LinuxBIOS or the payload. The disadvantage is
> that the video ROM gets compiled into both the fallback and normal LB
> RAM images (it takes up twice as much flash space as it needs to).
>
> I am wondering if it might be useful for LB to support some kind of
> flash partition structure (similar to Redboot) to allow storage of
> things common to both fallback and normal images, or to support user
> selection among two or more payloads.
>
> Steven J. Magnani               "I claim this network for MARS!
>  www.digidescorp.com              Earthling, return my space modulator!"
>
> #include <standard.disclaimer>
>
> LinuxBIOS mailing list
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios