On Thu, Dec 4, 2008 at 10:14 PM, Pattrick Hueper phueper@hueper.net wrote:
On Thu, Dec 4, 2008 at 5:39 PM, Myles Watson mylesgw@gmail.com wrote:
This is the same patch minus:
- The typedefs in types.h and multiboot.h ( s/uintXX_t/uXX/g)
- The -g in the Makefile
- An unrelated comment in stage0.s
Hi,
here is an updated patch series, no changes in types.h / multiboot.h anymore. You can ignore 0011-enable-debug-g.patch. The change in stage0_common.S was not part of my changes, it seem that it was introduced by a svn update Jordan did? ( it was commited by Carl-Daniel, i think).
Patty
Any comments from the rest of the list? There's still some cleanup to be done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
Thanks, Myles
2008/12/4 Pattrick Hueper phueper@hueper.net
On Thu, Dec 4, 2008 at 10:14 PM, Pattrick Hueper phueper@hueper.net wrote:
On Thu, Dec 4, 2008 at 5:39 PM, Myles Watson mylesgw@gmail.com wrote:
This is the same patch minus:
- The typedefs in types.h and multiboot.h ( s/uintXX_t/uXX/g)
- The -g in the Makefile
- An unrelated comment in stage0.s
Hi,
here is an updated patch series, no changes in types.h / multiboot.h anymore. You can ignore 0011-enable-debug-g.patch. The change in stage0_common.S was not part of my changes, it seem that it was introduced by a svn update Jordan did? ( it was commited by Carl-Daniel, i think).
Patty
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Dec 12, 2008 at 8:21 AM, Myles Watson mylesgw@gmail.com wrote:
Any comments from the rest of the list? There's still some cleanup to be done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
have not had a chance to test. If it will do no harm I'm ok with it.
ron
On 12.12.2008 17:27, ron minnich wrote:
On Fri, Dec 12, 2008 at 8:21 AM, Myles Watson mylesgw@gmail.com wrote:
Any comments from the rest of the list? There's still some cleanup to be done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
have not had a chance to test. If it will do no harm I'm ok with it.
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
That's why I'd prefer to have size measurements before committing this. Myles, can you do that? I'm rather unfamiliar with x86emu and my assessments might be wrong.
Regards, Carl-Daniel
-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Friday, December 12, 2008 10:17 AM To: ron minnich Cc: Myles Watson; Pattrick Hueper; coreboot@coreboot.org Subject: Re: [coreboot] [RFC] Here we go... the SLOF biosemu for coreboot- v3
On 12.12.2008 17:27, ron minnich wrote:
On Fri, Dec 12, 2008 at 8:21 AM, Myles Watson mylesgw@gmail.com wrote:
Any comments from the rest of the list? There's still some cleanup to
be
done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
have not had a chance to test. If it will do no harm I'm ok with it.
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
I built qemu with and without the patch with the emulator x86emu.
For me it takes 200 bytes in stage2/segment1 and 11 bytes in stage2/segment2.
Since it implements a few new opcodes, that's not surprising. I suppose we could make those opcodes dependent on using the new emulator, but it doesn't seem worth it.
With biosemu enabled, it takes just over 3K more in segment 1 and 31 bytes in segment 2. As advertised: larger, but not huge.
Thanks, Myles
Myles Watson wrote:
-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Friday, December 12, 2008 10:17 AM To: ron minnich Cc: Myles Watson; Pattrick Hueper; coreboot@coreboot.org Subject: Re: [coreboot] [RFC] Here we go... the SLOF biosemu for coreboot- v3
On 12.12.2008 17:27, ron minnich wrote:
On Fri, Dec 12, 2008 at 8:21 AM, Myles Watson mylesgw@gmail.com wrote:
Any comments from the rest of the list? There's still some cleanup to
be
done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
have not had a chance to test. If it will do no harm I'm ok with it.
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
I built qemu with and without the patch with the emulator x86emu.
For me it takes 200 bytes in stage2/segment1 and 11 bytes in stage2/segment2.
Since it implements a few new opcodes, that's not surprising. I suppose we could make those opcodes dependent on using the new emulator, but it doesn't seem worth it.
With biosemu enabled, it takes just over 3K more in segment 1 and 31 bytes in segment 2. As advertised: larger, but not huge.
And this code is arguably better and certainly more readable and hackable. I think the size increase is worthwhile.
Jordan
On Fri, Dec 12, 2008 at 9:17 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
sure, but, ultimately - correctness trumps size - to be frank, the ultimate utility of any emulator in v3 is an open question. I'm willing to let this one in for now as people seem to want it. Long term, however, we've decided on x86 to let seabios handle the vga task. I also think, long term, the SLOF stuff will similarly migrate to a payoad.
ron
From: ron minnich [mailto:rminnich@gmail.com]
On Fri, Dec 12, 2008 at 9:17 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
sure, but, ultimately
- correctness trumps size
- to be frank, the ultimate utility of any emulator in v3 is an open
question. I'm willing to let this one in for now as people seem to want it. Long term, however, we've decided on x86 to let seabios handle the vga task. I also think, long term, the SLOF stuff will similarly migrate to a payload.
So you'd rather that Pattrick and Kevin collaborate. I'm fine with that. I didn't want to see a developer submitting working code that's ignored.
Thanks, Myles
On Fri, Dec 12, 2008 at 10:44 AM, Myles Watson mylesgw@gmail.com wrote:
So you'd rather that Pattrick and Kevin collaborate. I'm fine with that. I didn't want to see a developer submitting working code that's ignored.
The conclusion we reached is that vga/rom setup is getting very complex, and that seabios does a very good job of it. Further, in most cases we need the interrupt vectors to remain active after the ROM has been executed. We felt it made no sense to replicate that capability in two places. So, yes, I think it makes the most sense in seabios.
thanks
ron
Hi,
i havent had time to look into seabios. What i read/heard of seabios, it seems, that it is pretty much tied with the x86 architecture, whereas the SLOF biosemu is designed to be architecture independent, and for me it has proven to be so by being ported from OF/PPC to coreboot/x86 with reasonable effort.
Being architecture independent, i think the biosemu has to keep its own set of Interrupt Vectors and virtual 1MB memory area (which is, by the way currently hard coded to 16MB of real memory i think...) That makes it possible to reenter biosemu e.g. for VBE calls (which we did in SLOF, the code is initializing the card by running the Option ROM first and later on reenters biosemu to switch to framebuffer mode). Of course in a x86 coreboot this might need to be redesigned... then again for a x86 coreboot, seabios or vm86 might be the better / faster choices anyway.
I started working on porting v3 to qemu-ppc... once i have some serial output, i will post patches. And i hope to hack qemu-ppc to use the same cirrus vga card and exprom and be able to initialize it in qemu-ppc though it remains to be seen, wether that will work or wether it is already there...
And then i am still planning to try to get some other devices (IDE/Ethernet) to work...
Also, would it be interesting for any of you if i tried to port biosemu to v2?
Regards, Pattrick
On Fri, Dec 12, 2008 at 7:57 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Dec 12, 2008 at 10:44 AM, Myles Watson mylesgw@gmail.com wrote:
So you'd rather that Pattrick and Kevin collaborate. I'm fine with that. I didn't want to see a developer submitting working code that's ignored.
The conclusion we reached is that vga/rom setup is getting very complex, and that seabios does a very good job of it. Further, in most cases we need the interrupt vectors to remain active after the ROM has been executed. We felt it made no sense to replicate that capability in two places. So, yes, I think it makes the most sense in seabios.
thanks
ron
From: Pattrick Hueper [mailto:phueper@hueper.net] Hi,
i havent had time to look into seabios. What i read/heard of seabios, it seems, that it is pretty much tied with the x86 architecture, whereas the SLOF biosemu is designed to be architecture independent, and for me it has proven to be so by being ported from OF/PPC to coreboot/x86 with reasonable effort.
Being architecture independent, i think the biosemu has to keep its own set of Interrupt Vectors and virtual 1MB memory area (which is, by the way currently hard coded to 16MB of real memory i think...) That makes it possible to reenter biosemu e.g. for VBE calls (which we did in SLOF, the code is initializing the card by running the Option ROM first and later on reenters biosemu to switch to framebuffer mode). Of course in a x86 coreboot this might need to be redesigned... then again for a x86 coreboot, seabios or vm86 might be the better / faster choices anyway.
I started working on porting v3 to qemu-ppc... once i have some serial output, i will post patches. And i hope to hack qemu-ppc to use the same cirrus vga card and exprom and be able to initialize it in qemu-ppc though it remains to be seen, wether that will work or wether it is already there...
I think this makes your case much stronger. I didn't realize you were porting v3 to PPC. You're right that seabios is x86-specific.
Myles
Pattrick Hueper wrote:
What i read/heard of seabios, it seems, that it is pretty much tied with the x86 architecture,
Yes. Everything runs natively. SeaBIOS provides the BIOS stuff needed by option ROMs.
whereas the SLOF biosemu is designed to be architecture independent, and for me it has proven to be so by being ported from OF/PPC to coreboot/x86 with reasonable effort.
It is great progress!
However, x86emu only really emulates real mode AFAIK, and not all option ROMs stick to that. They could assume that protected mode is available and enable it during their run. Have you looked into handling this also in biosemu? Have you seen this behavior in any option ROMs? Have you already done extensive testing?
//Peter
On Sat, Dec 13, 2008 at 5:41 AM, Peter Stuge peter@stuge.se wrote:
Pattrick Hueper wrote: However, x86emu only really emulates real mode AFAIK, and not all option ROMs stick to that. They could assume that protected mode is available and enable it during their run. Have you looked into handling this also in biosemu? Have you seen this behavior in any option ROMs? Have you already done extensive testing?
The code is used in the YDL Powerstation as part of SLOF, it is however, only executed for VGA Option ROMs, i.e. PCI Class 0x03 devices. Several graphics cards have been reported to be running with the latest SLOF code. I think it should succesfully initialise most graphics cards available as long as the initialisation happens in real mode.
I have done testing with an UltraIDE Controller the code did intialise the controller and PIO mode was working, i wanted to get DMA mode working through the interrupt handlers but didnt succeed and got moved to other projects before finishing. It also started executing a PXE Option ROM of a Gigabit Ethernet Controller (cant remember which one it was) but some parts of the PXE stack were missing.
I have never had an option ROM that tried to switch to protected mode, it wouldnt succeed with the x86emu anyway. However, e.g. the Graphics cards VBE calls are available in real and protected mode and they run perfectly in real mode, getting VGA info, detecting monitor EDIC data and switching framebuffer modes is all implemented in the vbe.c file and works in real mode.
I have also heard, that Benjamin Herrenschmidt is using the code in a user mode application, i think for initialisation of VGA cards in development of AMD Graphics Card Drivers for PPC Linux.
So i think the code is pretty well tested at least for VGA cards in non-x86 platforms, and it has proven to me, that it can be extended for other Option ROMs. Though the code for IDE and Ethernet Controllers has not been open sourced and it needs to be developed again.
I still think, that for x86 coreboot vm86 and seabios might be the better solution, but i thought that v3 was designed to be portable to other platforms, and for those i think the biosemu code can help, but probably not provide all functionality of seabios.
Also, i am not sure wether the code should be moved to a payload, at least not a standalone payload... if for example the code initialises a IDE controller, it would still need some other payload (or coreboot) to read a bootloader from the disk and start that...
Cheers, Pattrick
Pattrick Hueper wrote:
On Sat, Dec 13, 2008 at 5:41 AM, Peter Stuge peter@stuge.se wrote:
I still think, that for x86 coreboot vm86 and seabios might be the better solution, but i thought that v3 was designed to be portable to other platforms, and for those i think the biosemu code can help, but probably not provide all functionality of seabios.
Also, i am not sure wether the code should be moved to a payload, at least not a standalone payload... if for example the code initialises a IDE controller, it would still need some other payload (or coreboot) to read a bootloader from the disk and start that...
Indeed - there is still some question as to where the hybrid vm86/seabios or SLOF would live in the v3 ecosystem - I favor having the infrastructure live within coreboot itself, because it will be used globally by all systems. I think having it as a payload (even as a chained payload) is an additional build step that we don't need.
But thats a future discussion.
Jordan
ok, consensus seems to be we stick with SLOF in coreboot itself. Sorry for confusion. I'm interested in the v3 port to PPC.
Thanks pattrick for your work.
ron
On 12.12.2008 21:58, Pattrick Hueper wrote:
I started working on porting v3 to qemu-ppc... once i have some serial output, i will post patches. And i hope to hack qemu-ppc to use the same cirrus vga card and exprom and be able to initialize it in qemu-ppc though it remains to be seen, wether that will work or wether it is already there...
Wow! That's great news! If we can do anything to help you, please speak up. Especially if you find design decisions which make it difficult for you.
Regards, Carl-Daniel
On Sat, Dec 13, 2008 at 8:31 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Wow! That's great news! If we can do anything to help you, please speak up. Especially if you find design decisions which make it difficult for you.
I will. Currently i am still duplicating the x86 infrastructure and try to make it build... i will try to get some serial output working probably still in stage0 and will then post patches for you guys to review. Lets see if my kids give me some time for this around christmas ;-)
Cheers, Patty
do you have a mainboard you would recommend others test on once you are ready?
ron
On Fri, Dec 12, 2008 at 09:58:22PM +0100, Pattrick Hueper wrote:
i havent had time to look into seabios. What i read/heard of seabios, it seems, that it is pretty much tied with the x86 architecture, whereas the SLOF biosemu is designed to be architecture independent, and for me it has proven to be so by being ported from OF/PPC to coreboot/x86 with reasonable effort.
I wonder if YABEL could emulate SeaBIOS - that way, all the ugly bios code could be in one place (SeaBIOS). Currently, SeaBIOS will enter 32bit mode to do its initialization - I'm not sure if YABEL can handle that.
It may also be possible to compile the 32bit SeaBIOS code in native PPC mode and only emulate the 16bit code in YABEL.
Just some random thoughts..
-Kevin
On Fri, Dec 19, 2008 at 2:23 AM, Kevin O'Connor kevin@koconnor.net wrote:
I wonder if YABEL could emulate SeaBIOS - that way, all the ugly bios code could be in one place (SeaBIOS). Currently, SeaBIOS will enter 32bit mode to do its initialization - I'm not sure if YABEL can handle that.
Very interesting idea. Since x86emu does not emulate protected mode code, that code could not be emulated, but maybe it could be normal non-emulated C code that is used for initialization and then the 16 bit code could be emulated...
One concern i have is that i would like YABEL to still be a full BIOS emulator for SLOF, so i dont want to remove any of the BIOS emulation code... maybe we could find a way to share the code between the two emulators.. something like libbiosemu??
Then there is the licensing problem... YABEL is BSD licensed, i am assuming that SEABIOS is GPL? I would like YABEL to always be portable to SLOF which is BSD licensed as well...
It may also be possible to compile the 32bit SeaBIOS code in native PPC mode and only emulate the 16bit code in YABEL.
Ah, didnt read far enough ;-) Thats what i meant with the non-emulated initialization code above...
Cheers Patty
On 12.12.2008 19:57, ron minnich wrote:
On Fri, Dec 12, 2008 at 10:44 AM, Myles Watson mylesgw@gmail.com wrote:
So you'd rather that Pattrick and Kevin collaborate. I'm fine with that. I didn't want to see a developer submitting working code that's ignored.
The conclusion we reached is that vga/rom setup is getting very complex, and that seabios does a very good job of it. Further, in most cases we need the interrupt vectors to remain active after the ROM has been executed. We felt it made no sense to replicate that capability in two places. So, yes, I think it makes the most sense in seabios.
I'd say we go ahead and commit BIOSemu to v3 now and think about the SeaBIOS vs. BIOSemu decision later. After all, if we want to expand v3 beyond x86 (and some people really want that), we need an x86 emlulator anyway. It might as well be somehting that has been tested in production.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 12.12.2008 17:27, ron minnich wrote:
On Fri, Dec 12, 2008 at 8:21 AM, Myles Watson mylesgw@gmail.com wrote:
Any comments from the rest of the list? There's still some cleanup to be done, but it works as advertised. I'll Ack it and commit it if no one chimes in.
have not had a chance to test. If it will do no harm I'm ok with it.
There might be a considerable size increase if we take into account that our x86emu has been optimized for size by Ollie Lho.
Ollie Lho did a lot of awesome stuff, but I think to remember it was some italian guy that did this. Pattrick based his work on the x86emu version from v3, so there's nothing bad with it.
Stefan
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Kevin O'Connor -
Myles Watson -
Pattrick Hueper -
Peter Stuge -
ron minnich -
Stefan Reinauer