> 3. current VGA support in Porting guide. I guess We can put one link
> to point to testbios in FAQ, anyway FAQ part need to better
I might not think to look in the Porting Guide for VGA Support.
I suggest it be another topic off the main page. And maybe the Porting
Guide Page should include Ron's latest article - "Porting LinuxBIOS to
the AMD SC520"?
Thank you very much. The new page is very helpful.
Let me ask a few questions.
1. Does the new page describe onboard and addon card?
I expect the MB Config.lb would change for an addon card?
I assume the Config file would describe the PCI slots
and steps 2 & 3 would be the same for an addon card.
2. testbios is a third choice, which is useful if the
VGA image won't fit in the ROM device.
Should you move the testbios FAQ info to the VGA support page?
3. Will there be a link from the Main page to the VGA Support page?
From: yhlu [mailto:firstname.lastname@example.org]
Sent: Wednesday, August 10, 2005 6:47 PM
To: Li-Ta Lo
Cc: Kimball, Stephen; LinuxBIOS
Subject: Re: [LinuxBIOS] VGA support
I add some lines
Please check it and enrich it.
I am trying to use the PMC4 on the EPIA-SP ( vt8237 ) but can't write to
the internal flash.
I have code that can read and write successfully on a SST49LF004
installed in the top socket. However, when I throw the switch to the
internal flash (PMC Pm49FL004 ) I can read the flash ID via the
registers at ffbc0000 and 0001, but I can't read the ID via the typical
jedec cycle. Interestingly ( or not ) I seem to read back the last byte
written out in my code, e.g. a 0x90 0x90 is read as the ID after
completing the sequence to enter product ID mode ( which ends with a
write of 0x90).
I tried adding various sleeps to rule out timing issues. I am assuming
the vt8237 is operating in LPC mode as opposed to FWH; the datasheet for
the Pm49LF004 mentions it is read-compatible for FWH. I find it curious
that the 0x90 I mentioned above is the same BYTE i wrote out, rather
than some nibble-based variation like 99 or 00 (since LPC bus is 4
Any insight would be greatly appreciated. Thanks, Doug
> 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:
In Config.lb I reference a symbol defined in the wrapper:
device pci 0.0 on end
register "rom_address" = "_vgarom_start"
...and in my mainboard chip.h I forward-declare the symbol, so static.c
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!"
I am from India.
We are trying to boot Windows XP through LinuxBIOS ( freebios + BochsBIOS ).
We could load the XP image into the RAM but the int-16 is called for ever
after many int 13 calls.
Could you please help me with this respect
Narahari Murthy N.
Honeywell Technology Solutions Lab - Bangalore
151/1, Doraisanipalya, Bannerghatta Road
Bangalore - 560076, India
Ph: 91-80-26588360 ext. 2318
" If you love something, set it free. If it comes back to you, it's yours.
If it doesn't, it never was"
"You cannot believe in God until you believe in yourself" - Swami
"Our greatest glory consists not in never falling, but in rising every time
"In the end, we will remember not the words of our enemies, but the silence
of our friends"
Could someone explain the different VGA options with LinuxBIOS?
I've read the testbios FAQ items. This seems to be a utility program
that can be run after the system comes up to initialize a VGA card. Then
I suppose one could open an X window.
Then there are several LinuxBIOS Options that mention VGA:
Some VGA options are more useful than others. For example,
CONFIG_LEGACY_VGABIOS does not seem to be used.
I see CONFIG_CONSOLE_VGA enables logging to the VGA.
Could someone write a FAQ describing how to make CONFIG_CONSOLE_VGA
What topics will be covered at the LinuxBIOS Summit?
Will it be limited to technical issues and things that directly
affect technical issues such as access to chip set specifications,
NDA issues, new BIOS technologies and LinuxBIOS' competition, etc.?
Is making LinuxBIOS as popular and compelling as Linux and GNU/Linux
distributions a reasonable and desirable goal?
Would support of operating systems other than Linux such as OpenSolaris,
xBSD, Plan 9, and MS Windows 2000/XP be a reasonable goal? Perhaps,
a payload similar to ADLO could be used for non-Linux OSes.
LinuxBIOS is now extremely well designed and all the core developers
should get huge bonuses or well-deserved Kudos! However, sometimes
various mainboard builds break and some mainboard ports remain
incomplete. We need to support more chip sets and mainboards. How can
we do this? How can we make porting to new chip sets and mainboards easier?
We might try to generate a generic flash image for each mainboard
that people new to LinuxBIOS can download and use with minimal time
and effort required. It could ask a few simple questions to customize
the boot with the option to store the answers to NVRAM. This could
be taken to the extreme of a single Live CD that boots Linux and runs
a script that identifies the chip sets and mainboard and gives the user
the option of flashing his BIOS device with an appropriate LinuxBIOS
image (or one that at least supports all critical devices).
Will the LinuxBIOS Summit be rather open-ended like the above or will
there be a defined agenda or both?
Ken Fuchs <kfuchs(a)winternet.com>
After looking at the problems this "simple" commit caused, I've rolled
it back to the revision before my commit (2005->2003). I'll go over
these changes with Tom and Eric and try again later.
My apologies for any broken builds.
Jason W. Schildt
LinuxBIOS Software Engineer
I've just made a commit up to the public repository from the Linux
Networx repository mirror. The changes only effect Opteron single/dual
core and hdama board specific code.
Jason W. Schildt
LinuxBIOS Software Engineer