uups... forgot to add coreboot mailing list in this mail....
---------- Forwarded message ---------- From: Pattrick Hueper phueper@hueper.net Date: Sat, Dec 13, 2008 at 8:04 PM Subject: Re: [coreboot] [RFC] Here we go... the SLOF biosemu for coreboot-v3 To: ron minnich rminnich@gmail.com
Hi,
just one minor thing... ... SLOF is the Slimline Open Firmware developed by IBM for its Cell Blades and the YDL PowerStation... the biosemu is part of SLOF, and it seems soon part of coreboot :-) but i'd rather not call it SLOF since SLOF is a full IEEE1275 compliant OF implementation including Forth, Client Interface, ...
I dont really have a good name for it... in my first mail i called it YABEL (Yet another BIOS Emulation Layer) but that was intended as fun... can we call it biosemu? (x86emu is the processor emulation and biosemu the I/O / INT / Mem Emulation that makes the Option ROMs run...) Or does anybody have a better proposal?
Pattrick
On Sat, Dec 13, 2008 at 5:27 PM, ron minnich rminnich@gmail.com wrote:
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
Pattrick Hueper wrote:
I dont really have a good name for it... in my first mail i called it YABEL (Yet another BIOS Emulation Layer) but that was intended as fun... can we call it biosemu? (x86emu is the processor emulation and biosemu the I/O / INT / Mem Emulation that makes the Option ROMs run...) Or does anybody have a better proposal?
YABEL is a fine working name. The code in coreboot so far was more or less considered "libx86emu" even though that did not describe it completely.
Basically, YABEL is not a new direction. It fixes a lot of shortcomings in our v3 libx86emu code (from which some parts of YABEL were derived IIRC). So even if we decide to do SeaBIOS for the 16bit bios call part with x86emu at some point, chances are a lot better we can do that with YABEL than with what we have today. YABEL for example catches inb/outb to CF8/CFC and calls into PCI functions. This is good stuff. It could already be sufficient to get SeaBIOS working on PPC if we want/need it there.
Also, Pattrick's patches do fix some issues where x86emu behaved faulty with 32bit operands before. So some of the "32bit option roms" might even work that did not work before.
I'm all for merging Pattrick's nice work!
Stefan
On Sat, Dec 13, 2008 at 8:41 PM, Stefan Reinauer stepan@coresystems.de wrote:
Pattrick Hueper wrote:
YABEL is a fine working name. The code in coreboot so far was more or less considered "libx86emu" even though that did not describe it completely.
Ok, then i officialy baptize this code to the working name ... YABEL ;-)
Cheers, Patty
On Sat, Dec 13, 2008 at 1:43 PM, Pattrick Hueper phueper@hueper.net wrote:
On Sat, Dec 13, 2008 at 8:41 PM, Stefan Reinauer stepan@coresystems.de wrote:
Pattrick Hueper wrote:
YABEL is a fine working name. The code in coreboot so far was more or less considered "libx86emu" even though that did not describe it
completely.
Ok, then i officialy baptize this code to the working name ... YABEL ;-)
Can you sign it off as per the guidelines at
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
and change any code where you'd like it to be YABEL? Then I'll Ack and commit it.
Thanks, Myles
On 13.12.2008 22:18, Myles Watson wrote:
On Sat, Dec 13, 2008 at 1:43 PM, Pattrick Hueper phueper@hueper.net wrote:
On Sat, Dec 13, 2008 at 8:41 PM, Stefan Reinauer stepan@coresystems.de wrote:
Pattrick Hueper wrote:
YABEL is a fine working name. The code in coreboot so far was more or less considered "libx86emu" even though that did not describe it
completely.
Ok, then i officialy baptize this code to the working name ... YABEL ;-)
Can you sign it off as per the guidelines at
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
and change any code where you'd like it to be YABEL? Then I'll Ack and commit it.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
On Sat, Dec 13, 2008 at 10:18 PM, Myles Watson mylesgw@gmail.com wrote:
Can you sign it off as per the guidelines at
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
All the patches already contain a Signed-off-by line. Is that sufficient?
and change any code where you'd like it to be YABEL? Then I'll Ack and commit it.
Hm, would you like me to move it from the biosemu directory to a yabel directory? Otherwise i would just leave it as it is and refer to it as YABEL in the mails... I would like to keep the code close to the SLOF source code, since i would like to have fixes/enhancement in both repositories...
Patty
On 13.12.2008 22:39, Pattrick Hueper wrote:
On Sat, Dec 13, 2008 at 10:18 PM, Myles Watson mylesgw@gmail.com wrote:
Can you sign it off as per the guidelines at
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
All the patches already contain a Signed-off-by line. Is that sufficient?
Yes, of course. However, your thread starter mail didn't contain any Signed-off-by line and I didn't check the git log. That was probably the source of the misunderstanding.
I added the git log for reference.
commit b2d0ed51897b74c5a3cbc0a0c380b9624e7ebf61 Author: Pattrick Hueper phueper@hueper.net Date: Thu Dec 4 23:50:08 2008 +0100
replace all uintXX_t intXX_t in biosemu code
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 6fd47b4d8cc2b4d7ff1bcc7bf359809c4bd5576a Author: Pattrick Hueper phueper@hueper.net Date: Tue Dec 2 22:11:17 2008 +0100
enable debug (-g)
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 737b6a40467241bf863908be526c7817c6c07c86 Author: Pattrick Hueper phueper@hueper.net Date: Thu Nov 27 15:30:06 2008 +0100
disable DEBUG
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 0064fc1585e1a1d218b97c5dd59cf3488d992a38 Author: Pattrick Hueper phueper@hueper.net Date: Thu Nov 27 12:58:48 2008 +0100
it woiks, it woiks....
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 282e1a4d374e3a16c2f1ec522117ffe2ae403407 Author: Pattrick Hueper phueper@hueper.net Date: Thu Nov 27 10:24:11 2008 +0100
merge SLOF-JX-1.7.0-4 updates
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 59c1609030ba3b4fe5fd70400841c0c3ecba4395 Author: Pattrick Hueper phueper@hueper.net Date: Thu Nov 27 10:06:37 2008 +0100
yipieeh... it builds... and starts... doesnt work yet, though :-( Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 2957f93794f3f039bbeac3a277fdcd44d76284ae Author: Pattrick Hueper phueper@hueper.net Date: Mon Nov 24 22:48:06 2008 +0100
biosemu needs libgcc... just as x86emu does
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 151d21c17555fcf87c235efb93ae98bd59d09ecf Author: Pattrick Hueper phueper@hueper.net Date: Mon Nov 24 22:01:46 2008 +0100
fix build warnings in x86emu, especially with -DDEBUG
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 2f1acf88bbd7d3fc9535357c5282fe807d5a5b12 Author: Pattrick Hueper phueper@hueper.net Date: Mon Nov 24 21:46:24 2008 +0100
x86emu changes from slof-JX-1.0.7-4
implemented bswap opcodes, some tracing fixes, small bugfixes
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 9644fedf2dbbb2b3bcd4331758bc2e6a335ee8af Author: Pattrick Hueper phueper@hueper.net Date: Mon Nov 24 12:17:54 2008 +0100
x86emu changes and fixes from slof
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 94fe38a7b6d5ca7965c60e053afa4baef16744cc Author: Pattrick Hueper phueper@hueper.net Date: Sun Nov 23 11:40:21 2008 +0100
build integration of biosemu
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 0aab2795a986e76286386ebd02e59ca75a528538 Author: Pattrick Hueper phueper@hueper.net Date: Sun Nov 23 11:04:32 2008 +0100
original biosemu version, copied from slof-JX-1.7.0-1
Signed-off-by: Pattrick Hueper phueper@hueper.net
commit 0b61af8d4829535e6d90fee26c0e7d0aec09435d Author: Pattrick Hueper phueper@hueper.net Date: Sat Nov 22 22:40:59 2008 +0100
add .gitignore
Signed-off-by: Pattrick Hueper phueper@hueper.net
and change any code where you'd like it to be YABEL? Then I'll Ack and commit it.
Hm, would you like me to move it from the biosemu directory to a yabel directory? Otherwise i would just leave it as it is and refer to it as YABEL in the mails... I would like to keep the code close to the SLOF source code, since i would like to have fixes/enhancement in both repositories...
The biosemu directory sounds fine.
There's one thing we have to decide on, though. Should all of this be committed as one big block or is a split into multiple patches preferable? I'd like at least one commit which mirrors the YABEL part of the SLOF tree (commit 0aab2795a986e76286386ebd02e59ca75a528538). Later changes can be grouped, but it never huts to have a reference point available, especially if there is a chance that the YABEL codebase may get some fixes in SLOF.
Regards, Carl-Daniel
Pattrick Hueper wrote:
Otherwise i would just leave it as it is and refer to it as YABEL in the mails...
Pick one name, and use it both for code and communication. Anything else is marketing suicide, don't do that.
//Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Sunday, December 14, 2008 6:49 PM To: coreboot@coreboot.org Subject: Re: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu forcoreboot-v3
Pattrick Hueper wrote:
Otherwise i would just leave it as it is and refer to it as YABEL in the mails...
Pick one name, and use it both for code and communication. Anything else is marketing suicide, don't do that.
Agreed. At least the Kconfig variable name (currently biosemu) should match what you call it on the mailing list.
Myles
Ok, i will change the Kconfig name and the directory.
I would not like to change the filename biosemu.c cause that makes merging with the slof.git harder. Would that be ok?
One more thing... YABEL currently needs 1MB of memory for its "virtual" memory to store INT Vectors, ROM Image, ... it is currently hard coded to 16MB, should i move this to Kconfig as well and what would be a good default location?
Cheers, Patty
On Mon, Dec 15, 2008 at 4:46 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Sunday, December 14, 2008 6:49 PM To: coreboot@coreboot.org Subject: Re: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu forcoreboot-v3
Pattrick Hueper wrote:
Otherwise i would just leave it as it is and refer to it as YABEL in the mails...
Pick one name, and use it both for code and communication. Anything else is marketing suicide, don't do that.
Agreed. At least the Kconfig variable name (currently biosemu) should match what you call it on the mailing list.
Myles
-----Original Message----- From: Pattrick Hueper [mailto:phueper@hueper.net] Sent: Monday, December 15, 2008 10:31 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] Fwd: [RFC] Here we go... the SLOF biosemu forcoreboot-v3
Ok, i will change the Kconfig name and the directory.
Thanks.
I would not like to change the filename biosemu.c cause that makes merging with the slof.git harder. Would that be ok?
That's fine with me.
One more thing... YABEL currently needs 1MB of memory for its "virtual" memory to store INT Vectors, ROM Image, ... it is currently hard coded to 16MB, should i move this to Kconfig as well?
Yes.
and what would be a good default location?
16MB sounds fine for now.
Thanks, Myles
Pattrick Hueper wrote:
Ok, i will change the Kconfig name and the directory.
I would not like to change the filename biosemu.c cause that makes merging with the slof.git harder. Would that be ok?
If that file is effectively the entire work, then I think it could definately have the same name as the project/repo/directory.
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
However - would it not be desirable to unify enough code so that you can use the same repo both for SLOF and coreboot?
One more thing... YABEL currently needs 1MB of memory for its "virtual" memory to store INT Vectors, ROM Image, ... it is currently hard coded to 16MB, should i move this to Kconfig as well and what would be a good default location?
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
Or implement an algorithm in code that looks at available memory and navigates around any reserved areas. I like that better.
//Peter
On Mon, Dec 15, 2008 at 7:28 PM, Peter Stuge peter@stuge.se wrote:
Pattrick Hueper wrote:
Ok, i will change the Kconfig name and the directory.
I would not like to change the filename biosemu.c cause that makes merging with the slof.git harder. Would that be ok?
If that file is effectively the entire work, then I think it could definately have the same name as the project/repo/directory.
It is not the entire work, only the entry point for BIOS emulation and setup code.
Work is split into several files:
- Interrupt Handling in interrupt.c - memory in mem.c - I/O in io.c - VBE in vbe.c - some generic device functions in device.c - ...
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
Ok, i will leave it as it is then.
However - would it not be desirable to unify enough code so that you can use the same repo both for SLOF and coreboot?
Yes, thats why i want to keep the filenames the same, makes keeping one repository and pushing into SLOF/coreboot easier.
One more thing... YABEL currently needs 1MB of memory for its "virtual" memory to store INT Vectors, ROM Image, ... it is currently hard coded to 16MB, should i move this to Kconfig as well and what would be a good default location?
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
Ok, i will do that and sent updated patches.
Or implement an algorithm in code that looks at available memory and navigates around any reserved areas. I like that better.
That sounds great but i will probably do that in another step?
Patty
Hi,
On Mon, Dec 15, 2008 at 7:28 PM, Peter Stuge peter@stuge.se wrote:
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
...
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
here are two more patches,
- rename biosemu to YABEL in Kconfig, CONFIG variables and directory - make the virtual memory location and size editable in Kconfig
I couldn't figure out a way to tell Kconfig that the VIRTMEM variables depend on EXPERT to be visible in menu, but still must be set in .config if EXPERT is not set but YABEL is set. Thus i introduced a workaround in yabel/compat/functions.c to detect wether the CONFIG_xxx variables are defined and if they are not defined, default to 16MB/1MB size. In this workaround i dont like the fact, that the defaults (16MB for location, 1MB for size) are set twice... once in Kconfig if EXPERT and once in yabel/compat/functions.c if !EXPERT and thus no CONFIG_xxx variables. Any recommendations for that problem?
If you approve of these two patches i will merge them into the patch set that contains the complete series and is only made up of 4 patches and repost that series.
Signed-off-by: Pattrick Hueper phueper@hueper.net
Cheers, Patty
On Tue, Dec 16, 2008 at 6:14 AM, Pattrick Hueper phueper@hueper.net wrote:
Hi,
On Mon, Dec 15, 2008 at 7:28 PM, Peter Stuge peter@stuge.se wrote:
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
...
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
here are two more patches,
- rename biosemu to YABEL in Kconfig, CONFIG variables and directory
- make the virtual memory location and size editable in Kconfig
I don't think the size should be a config option. Why should the size change? If it is to add features, the features should be the config options.
I couldn't figure out a way to tell Kconfig that the VIRTMEM variables depend on EXPERT to be visible in menu, but still must be set in .config if EXPERT is not set but YABEL is set. Thus i introduced a workaround in yabel/compat/functions.c to detect wether the CONFIG_xxx variables are defined and if they are not defined, default to 16MB/1MB size. In this workaround i dont like the fact, that the defaults (16MB for location, 1MB for size) are set twice... once in Kconfig if EXPERT and once in yabel/compat/functions.c if !EXPERT and thus no CONFIG_xxx variables. Any recommendations for that problem?
I would take out the default setting in Kconfig. If the person has to be an expert to change it, and they're changing it, there shouldn't be a default.
Thanks, Myles
On Tue, Dec 16, 2008 at 5:21 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 16, 2008 at 6:14 AM, Pattrick Hueper phueper@hueper.net wrote:
Hi,
On Mon, Dec 15, 2008 at 7:28 PM, Peter Stuge peter@stuge.se wrote:
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
...
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
here are two more patches,
- rename biosemu to YABEL in Kconfig, CONFIG variables and directory
- make the virtual memory location and size editable in Kconfig
Ok, thats true... i will remove it... i have played with more than 1MB virtual memory once, but it isnt really needed...
I would take out the default setting in Kconfig. If the person has to be an expert to change it, and they're changing it, there shouldn't be a default.
Hm... taking out the default would mean, that if you select expert you _have_ to enter a value... since it is not preset? That seems a little bit too much expertism to expect... providing a sensible default seems to make sense IMHO.
Patty
On Tue, Dec 16, 2008 at 9:26 AM, Pattrick Hueper phueper@hueper.net wrote:
On Tue, Dec 16, 2008 at 5:21 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 16, 2008 at 6:14 AM, Pattrick Hueper phueper@hueper.net
wrote:
Hi,
On Mon, Dec 15, 2008 at 7:28 PM, Peter Stuge peter@stuge.se wrote:
On the other hand, it is of course expected to have descriptive file names, which makes biosemu.c a good name for a file doing BIOS emulation in any case.
...
It could go into Kconfig but users should not be bothered with it. Maybe make it changeable for experts only.
here are two more patches,
- rename biosemu to YABEL in Kconfig, CONFIG variables and directory
- make the virtual memory location and size editable in Kconfig
Ok, thats true... i will remove it... i have played with more than 1MB virtual memory once, but it isnt really needed...
I would take out the default setting in Kconfig. If the person has to be
an
expert to change it, and they're changing it, there shouldn't be a
default.
Hm... taking out the default would mean, that if you select expert you _have_ to enter a value... since it is not preset? That seems a little bit too much expertism to expect... providing a sensible default seems to make sense IMHO.
You're right, that also doesn't make sense. I meant make it so that you have to provide a value if you want to change it. So could you introduce a boolean that deafaults to false and depends on expert that is "set the address for yabel", then not have a default for the address.
Thanks, Myles
On Tue, Dec 16, 2008 at 5:28 PM, Myles Watson mylesgw@gmail.com wrote:
Ok, thats true... i will remove it... i have played with more than 1MB virtual memory once, but it isnt really needed...
...
You're right, that also doesn't make sense. I meant make it so that you have to provide a value if you want to change it. So could you introduce a boolean that deafaults to false and depends on expert that is "set the address for yabel", then not have a default for the address.
Thanks, Myles
Update patch attached. Removed size setting, changed location setting as proposed.
Patty
On Tue, Dec 16, 2008 at 10:01 AM, Pattrick Hueper phueper@hueper.netwrote:
On Tue, Dec 16, 2008 at 5:28 PM, Myles Watson mylesgw@gmail.com wrote:
Ok, thats true... i will remove it... i have played with more than 1MB virtual memory once, but it isnt really needed...
...
You're right, that also doesn't make sense. I meant make it so that you have to provide a value if you want to change it. So could you introduce
a
boolean that deafaults to false and depends on expert that is "set the address for yabel", then not have a default for the address.
Thanks, Myles
Update patch attached. Removed size setting, changed location setting as proposed.
Looks good, but I don't see the default value. It's just in the comment. If you add the default value and send the updated patches, we can commit.
Thanks, Myles
On Tue, Dec 16, 2008 at 10:05 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 16, 2008 at 10:01 AM, Pattrick Hueper phueper@hueper.netwrote:
On Tue, Dec 16, 2008 at 5:28 PM, Myles Watson mylesgw@gmail.com wrote:
Ok, thats true... i will remove it... i have played with more than 1MB virtual memory once, but it isnt really needed...
...
You're right, that also doesn't make sense. I meant make it so that you have to provide a value if you want to change it. So could you
introduce a
boolean that deafaults to false and depends on expert that is "set the address for yabel", then not have a default for the address.
Thanks, Myles
Update patch attached. Removed size setting, changed location setting as proposed.
Looks good, but I don't see the default value. It's just in the comment. If you add the default value and send the updated patches, we can commit.
Now you think I'm a nut. I am :)
You don't need to add the default value, the comment made me think there should be one there. You could change the wording there, or not. This is starting to get too picky for an initial commit.
Sorry.
Myles
On Tue, Dec 16, 2008 at 6:07 PM, Myles Watson mylesgw@gmail.com wrote:
You don't need to add the default value, the comment made me think there should be one there. You could change the wording there, or not. This is starting to get too picky for an initial commit.
I just wanted to give the expert user an indication what is the default value in the code... thats why i put it in the help
Patty
On Tue, Dec 16, 2008 at 10:22 AM, Pattrick Hueper phueper@hueper.netwrote:
On Tue, Dec 16, 2008 at 6:07 PM, Myles Watson mylesgw@gmail.com wrote:
You don't need to add the default value, the comment made me think there should be one there. You could change the wording there, or not. This
is
starting to get too picky for an initial commit.
I just wanted to give the expert user an indication what is the default value in the code... thats why i put it in the help
I understood that as soon as I sent the mail. That was why I said you could change the wording or not. The meaning I think you wanted was "the code defaults to 0x1000000", and the meaning I got from the comment was "this value defaults to 0x1000000."
It's not that important.
Thanks, Myles
Hi, I found what seems to be a bug in the current yabel/biosemu.c. You seem to have addressed it in a patch already, though..
Pattrick Hueper wrote: ..
+u32 +biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev) +{
..
- // setup default Interrupt Vectors
- // some expansion ROMs seem to check for these addresses..
- // each handler is only an IRET (0xCF) instruction
- // ROM BIOS Int 10 Handler F000:F065
- my_wrl(0x10 * 4, 0xf000f065);
- my_wrb(0x000ff065, 0xcf);
Has this gotten some feedback? The fix is correct!
//Peter
Hi,
On Wed, Jan 7, 2009 at 12:51 AM, Peter Stuge peter@stuge.se wrote:
Hi, I found what seems to be a bug in the current yabel/biosemu.c. You seem to have addressed it in a patch already, though..
Pattrick Hueper wrote: ..
+u32 +biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev) +{
..
// setup default Interrupt Vectors// some expansion ROMs seem to check for these addresses..// each handler is only an IRET (0xCF) instruction// ROM BIOS Int 10 Handler F000:F065my_wrl(0x10 * 4, 0xf000f065);my_wrb(0x000ff065, 0xcf);Has this gotten some feedback? The fix is correct!
This code is currently in svn, isnt it? It should be correct, all it does is let the INT10 int handler point to F000:F065 (the default location) and the code at that location is 0xCF (IRET).
Patty
Pattrick Hueper wrote:
my_wrl(0x10 * 4, 0xf000f065);my_wrb(0x000ff065, 0xcf);Has this gotten some feedback? The fix is correct!
This code is currently in svn, isnt it?
Yes - I was looking at an older patch. Thanks!
//Peter
On 13.12.2008 20:05, Pattrick Hueper wrote:
uups... forgot to add coreboot mailing list in this mail....
---------- Forwarded message ---------- From: Pattrick Hueper phueper@hueper.net Date: Sat, Dec 13, 2008 at 8:04 PM Subject: Re: [coreboot] [RFC] Here we go... the SLOF biosemu for coreboot-v3 To: ron minnich rminnich@gmail.com
Hi,
just one minor thing... ... SLOF is the Slimline Open Firmware developed by IBM for its Cell Blades and the YDL PowerStation... the biosemu is part of SLOF, and it seems soon part of coreboot :-) but i'd rather not call it SLOF since SLOF is a full IEEE1275 compliant OF implementation including Forth, Client Interface, ...
I dont really have a good name for it... in my first mail i called it YABEL (Yet another BIOS Emulation Layer) but that was intended as fun... can we call it biosemu? (x86emu is the processor emulation and biosemu the I/O / INT / Mem Emulation that makes the Option ROMs run...) Or does anybody have a better proposal?
Your code, your naming choice. It's that simple. :-)
Regards, Carl-Daniel
On Sat, Dec 13, 2008 at 11:42 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Your code, your naming choice. It's that simple. :-)
but we welcome you to continue the cool looking animal theme we got with the coreboot logo :-)
ron
-
Carl-Daniel Hailfinger -
Myles Watson -
Pattrick Hueper -
Peter Stuge -
ron minnich -
Stefan Reinauer