That could solve some problem about font memory initilization.
But I guess the problem is about Emulator, and Ron is digging that on S2885 now. With LinuxBIOS (enable VGA and copy that to RAM but don't run_BIOS) + test bios.
Stefan,
What's the onboard VGA? are your talking about onboard one?
YH
-----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Tuesday, February 08, 2005 12:53 PM To: Li-Ta Lo Cc: LinuxBIOS Subject: Re: VGA option rom code broken?
- Li-Ta Lo ollie@lanl.gov [050208 21:22]:
YhLu reversed the order of apic_cluster and northbridge in
mainboard
config file. Did you change your config file too?
No, do I need to? What is the exact benefit except only having to mention one apic_cluster? If this is the problem we will have to change it in most ports I guess.
Stefan
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
* YhLu YhLu@tyan.com [050209 01:48]:
Stefan,
What's the onboard VGA? are your talking about onboard one?
YH
Yes, it is an onboard rage xl. Pretty much the same as on all opteron boards i guess.
It looks like x86emu can't see the rom itself? I manually checked the image and it looks ok
Stefan
On Tue, 8 Feb 2005, YhLu wrote:
But I guess the problem is about Emulator, and Ron is digging that on S2885 now. With LinuxBIOS (enable VGA and copy that to RAM but don't run_BIOS) + test bios.
some more detail on this. We have temporarily modified linuxbios to do everything EXCEPT actually run the emulator. This ensures that the routing is right in 18:1 etc. but allows us to defer running the bios until we can run the user mode testbios.
I think that a CMOS setting and/or build time option to enable this would be very useful.
ron
On Wed, 2005-02-09 at 10:22, Ronald G. Minnich wrote:
On Tue, 8 Feb 2005, YhLu wrote:
But I guess the problem is about Emulator, and Ron is digging that on S2885 now. With LinuxBIOS (enable VGA and copy that to RAM but don't run_BIOS) + test bios.
some more detail on this. We have temporarily modified linuxbios to do everything EXCEPT actually run the emulator. This ensures that the routing is right in 18:1 etc. but allows us to defer running the bios until we can run the user mode testbios.
I think that a CMOS setting and/or build time option to enable this would be very useful.
Is the routing correct? Can you see the vbios image at 0xc0000?
You are using S2885 right?
Ollie
On Wed, 9 Feb 2005, Li-Ta Lo wrote:
Is the routing correct? Can you see the vbios image at 0xc0000?
it seems to be right -- I see the vbios image.
But: it seems the a000 space is not right. Not sure yet.
ron
On Wed, 2005-02-09 at 10:37, Ronald G. Minnich wrote:
On Wed, 9 Feb 2005, Li-Ta Lo wrote:
Is the routing correct? Can you see the vbios image at 0xc0000?
it seems to be right -- I see the vbios image.
But: it seems the a000 space is not right. Not sure yet.
ron
I just did the regression test on the stack of vga cards here. Every previously working card still works for the current CVS tree. It must be something we have not seen before.
Did you get scrambled screen or a blank one?
Ollie
On Wed, 9 Feb 2005, Li-Ta Lo wrote:
Did you get scrambled screen or a blank one?
for our cards, we get one scrambled screen, and one blank one. In X, we get a scrambled screen.
here's a great one. For the NV5500 ($500 card), if we don't connect the external hard drive power connector, the card works under X!
ron
-Linux bios team http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip Looks like via is passing out linux bios, with out ever saying any thing about GPL or linuxbios.org... -Adam
On Wed, 9 Feb 2005, Adam Talbot wrote:
-Linux bios team http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip Looks like via is passing out linux bios, with out ever saying any thing about GPL or linuxbios.org...
we've got a couple of GPL violators in the linuxbios space. I know Orion Microsystems has got caught between a rock and a hard place and is distributing linuxbios-based systems without releasing sources; I have no idea if this via fastboot is linuxbios or not; via denies that it is.
I don't have the energy to pursue these guys.
ron
Looking for the configs for the EPIA-MII, i dont see them in the freebios2 tree. Should I just build them from scratch? -Adam
On Thu, 10 Feb 2005, Adam Talbot wrote:
Looking for the configs for the EPIA-MII, i dont see them in the freebios2 tree. Should I just build them from scratch?
sure.
ron
How fast is the ROM chip MB/s. In my case a SST 39SF020A 70-4C-NH. I was trying to figure out what would be faster... Linuxbios calling a 2.6 kernel off the hard drive, or loading my 2.6 kernel out of the rom file. I have the 512k rom chips, so I have room to add my kernel. If I put my kernel into the rom, can I just call it as a payload? -Adam
yes, you can make the kernel the payload.
if you get a kernel into 512kb, I want your .config file!
ron
On Fri, 11 Feb 2005 08:32:43 -0800, Adam Talbot talbotx@comcast.net wrote:
How fast is the ROM chip MB/s. In my case a SST 39SF020A 70-4C-NH. I was trying to figure out what would be faster... Linuxbios calling a 2.6 kernel off the hard drive, or loading my 2.6 kernel out of the rom file. I have the 512k rom chips, so I have room to add my kernel. If I put my kernel into the rom, can I just call it as a payload? -Adam
Your challenge won't be loading speed but rather getting a kernel in 512k.
That said my first guess is that in ROM is going to be much faster on all but a few special cases but lets just do some math and see...
For loading from the BIOS chip you are talking ISA cycles. Which is approx 1uS per cycle but you are only going to get 8 bits at a time unless you happend to have a 16-Bit flash.
Lets neglect RAM speed since it should be the same in both cases.
The string copy functions of x86 assembly will let you set up a block memory move with basiclly no overhead. So you should be able to load the entire ROM into a block of RAM in 525 mS.
Reading from IDE will happen over the PCI bus which is much faster. I don't really know what the actual cycle time of PCI is sine it varies but the clock is 4 tims faster so lets assume we can get 4x the cycle rate or 250 ns per cycle. Ide devices are 16 bit so we are going to approx 8x the data rate. However, the HD involes a seek for every 512 16 bit words. I don't think FILO takes advantage of the streaming commands. So for every 1kb we are talking 128uS of data time and 10 to 12 ms avg seek. so 512 x 12.128 mS give you 6.2 seconds.
But thats a worst case number and neglects the cache of a modern HD. If the HD is able to cache up the entire 512k so the seek times are 0 then the number would have a low of .128 mS * 512 = 65mS. That's negelecting the overhead with issuing the read commands to the IDE device so in reality its higher than that.
So the only answer is you have to test and see. Could be faster could be slower. Also if you take in account harddisk spinup time from a cold boot which is always going to be larger than .5s it in ROM will be faster. But if you use something like a compact flash you don't have the hd platter spinup time. Then its going to depend on the device.
I'd be intersted in hearing about your results.
On Thu, 2005-02-10 at 09:30 -0700, Ronald G. Minnich wrote:
I don't have the energy to pursue these guys.
None of us probably do, but the Software Freedom Law Center might, and this sort of thing is right down their alley as non-profit defenders of the FOSS licensing ecosystem. These kinds of violations hurt the entire FOSS community, and need to be pursued by somebody -- eventually, with enough violations, the courts will decide that we weren't serious about the FOSS licenses anyway, and throw them out.
Might at least be worth an email to them:
On Thu, 10 Feb 2005, Al Hooton wrote:
None of us probably do, but the Software Freedom Law Center might, and this sort of thing is right down their alley as non-profit defenders of the FOSS licensing ecosystem. These kinds of violations hurt the entire FOSS community, and need to be pursued by somebody -- eventually, with enough violations, the courts will decide that we weren't serious about the FOSS licenses anyway, and throw them out.
I did that, but after one or two emails heard no more from them.
ron
Ronald G. Minnich wrote:
On Wed, 9 Feb 2005, Adam Talbot wrote:
-Linux bios team http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip Looks like via is passing out linux bios, with out ever saying any thing about GPL or linuxbios.org...
we've got a couple of GPL violators in the linuxbios space. I know Orion Microsystems has got caught between a rock and a hard place and is distributing linuxbios-based systems without releasing sources; I have no idea if this via fastboot is linuxbios or not; via denies that it is.
I don't have the energy to pursue these guys.
A quick peek through the binary shows:
Build Boot notes ... LinuxBIOS Build boot notes [FIRMWARE_TYPE](0x%x) ... ok LinuxBIOS Build boot notes [BOOTLOADER_NAME](0x%x)
Hmmm... what's this in here?
I've always found VIA to be pretty helpful. Maybe someone can politely contact them for more info.
-Bari
On Thu, 10 Feb 2005, Ronald G. Minnich wrote:
-Linux bios team http://www.viaarena.com/guides/WinCE/fastboot%20v2.03.zip Looks like via is passing out linux bios, with out ever saying any thing about GPL or linuxbios.org...
we've got a couple of GPL violators in the linuxbios space. I know Orion Microsystems has got caught between a rock and a hard place and is distributing linuxbios-based systems without releasing sources; I have no idea if this via fastboot is linuxbios or not; via denies that it is.
I downloaded the above zip file, unzipped it and did a quick 'strings */BIOS* | grep -i linux' which resulted in:
Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Found file system used by Linux.(File System ID = 0x%x) LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) bash-2.05b$ strings */* | grep -i linux Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Not a Linux kernel image. Linux(non-ELF), Linux version is very old. LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Linux(non-ELF), Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Found file system used by Linux.(File System ID = 0x%x) LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Found file system used by Linux.(File System ID = 0x%x) LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Found file system used by Linux.(File System ID = 0x%x) LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx)
Perhaps FSF or EFF can help?
Best regards
Peter K
* Peter Karlsson petekarl@student.chalmers.se [050210 19:58]:
Try to load Linux(0x%x) at dev 0x%x LinuxBIOS LinuxBIOS Jump to Linux(0x%lx, 0x%lx) Jump to Linux(0x%lx, 0x%lx) Found file system used by Linux.(File System ID = 0x%x) LinuxBIOS Try to load Linux(0x%x) at dev 0x%x
[..]
From those strings it actually doesn't look like they are using
LinuxBIOS but rather chose the same name. But then again, changing a couple of strings is nothing too hard.
The way to go is rather to convince them to go with the real LinuxBIOS[tm] in future.
Stefan
On Thu, Feb 10, 2005 at 11:25:17PM +0100, Stefan Reinauer wrote:
From those strings it actually doesn't look like they are using
LinuxBIOS but rather chose the same name. But then again, changing a couple of strings is nothing too hard.
I guess Fastboot builds LinuxBIOS Tables and ELF Boot Notes in RAM to boot ELF images (they instructs to use mkelfimage to boot linux). So the "LinuxBIOS" strings might be ones to go to some of these tables?
OTOH, I've found those strings that are very similar to those found in FILO...
ts1@felixx:/tmp/CDRom$ strings BIOS_D.BIN | grep "Not a" Not a bootable ELF image Not a Linux kernel image.
ts1@felixx:~/src/ts1/filo$ grep -r "Not a" . ./i386/linux_load.c: debug("Not a Linux kernel image\n"); ./main/elfload.c: debug("Not a bootable ELF image\n");
-
Adam Talbot -
Al Hooton -
Bari Ari -
Li-Ta Lo -
Peter Karlsson -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer -
Takeshi Sone -
YhLu