General Category => PC EFI => Topic started by: Krule on May 24, 2008, 03:30:56 PM

Title: An idea(s)
Post by: Krule on May 24, 2008, 03:30:56 PM
PC EFI has done wonders so far, but I kinda bugs me on what is next. I have been doing some thinking on how to elegantly solve hardware support and multi OS environment.

So here is my idea. Keep in mind that it just that, an idea, from a person with severely limited technical background in *nix or OSX environment. I hope this will not cause flame on me for stupidity of my idea.

1. Hardware
This is something that has been bugging everyone. Honestly, good information on this subject requires a lot of research time. Also there are various techniques used to solve problems, of which I have found that PC EFI is the best one.

In order for some hardware piece to work, correct me if I am wrong, we need to get/create .plist, check if certain values are correct, incorporate it out existing .plist (with hardware that already woks), create a "string" out of it, and glue the "string" to Boot.plist.

While this approach is nice, it certainly is not user friendly.

Idea I had on this would be to use/create cocoa based application which uses lspci in order to get information on hardware, then submit query base on that data to web repository (which address should be changable) for each piece of hardware, where hardware xml (plist) is stored in a database. Application should then create one large plist file based on response from repository . After this it should be able to convert it to string using gfxutil (eventually to create new Boot.plist, backing up the old one and giving options for manual changes).

Web repository should be user maintained.

I have no idea if this would work, but I am learning about programing in Xcode, and will give it a try, as soon as I learn enough. Web repository(es) is not a hard thing to create, a day or two in Rails.

2. PC EFI (Efi Emulator) as bootloader
Essentially I have no idea on what are the limitations on EFI emulation. I have been trying to get some more data on it, but it is not easy to come by. However, from what I have found on EFI, so far, it looks as enormous leap forward from BIOS.

Idea would be to use single mini drive (small HDD or flash drive [SATA mini disc sounds sweet]) for EFI emulation. After we set BIOS to boot from it, emulated EFI would then take over (maybe having some microkernel as core) detecting drives with OS on them and passing hardware information to selected OS. After OS selection is done, EFI (& microkernel) is unloaded or not depending on OS selected. This EFI should be able to have some GUI at least.

Advantage here is that this emulated EFI would be easily updated using already mentioned software, and that OS X should think it is real mac.

Anyway, If I have understood it correctly this idea should as least be plausible.

That is it, I would love to hear is this, at least, plausible.

Title: Re: An idea(s)
Post by: MoDs on May 24, 2008, 05:14:40 PM
OMG! Idea number 1 was exactly what i was thinking about! I am a CS student, but i'm a recent switcher, so i'd take me some time to get used to it.

1st things 1st: how we gonne redirect the output of the terminal to our code so that we use the output of "lspci"?

Anyway, it's a great idea, and soon will be real :)


Title: Re: An idea(s)
Post by: inside on May 24, 2008, 06:15:21 PM

maybe i can add the 1st part to my gfxutli frontend that can be found here:,64.60.html (,64.60.html)

@MoDs: redirecting the terminal output is done with NSTask in cocoa.  ;)

Title: Re: An idea(s)
Post by: Krule on May 26, 2008, 12:08:16 PM
I have started modelling a database for this project. When I get some time on my hands, I will build a web app as well.

So far, I have modelled 1st version of database (model can be seen on picture).

I started with several assumptions.

1. Repository is to be user maintained
This also means that mechanism for user login/registration is necessary. I have used a minimal email/password model here, with extended user data optional.

2. One device can have more than one XML
Well, more or less. :) Version (huge change)/Revision (small change) system ensures that particular XML changes can be tracked. It also gives user possibility to get version/revision that has been confirmed as one that works.

3. lspci printout = device
This should be self-explanatory. lspci data is stored into database as simple and as verboxe --v output. lspci simple output is the device (name).

4. device does not require XML
While it is nice to have XML for each device, reality is that a lot of them will not. However, queries (query = lspci printout) from Cocoa based application can be stored as devices which should create device base.

I think I have covered most of it. Further input would be nice.

# On the side note, where can I find nice Cocoa development resources/tutorials/books.

Title: Re: An idea(s)
Post by: inside on May 26, 2008, 07:11:18 PM
# On the side note, where can I find nice Cocoa development resources/tutorials/books.
apples xCode is for free, and all dokumentations too.
the best book to start with cooca is "Cocoa Programming for Mac OS X" by Aaron Hillegass.

Title: Re: An idea(s)
Post by: websrvr on June 04, 2008, 12:18:06 AM
While this is a nice approach and I commend you on your initiative, there are some stumbling blocks that are going to hinder development, first, source that would be beneficial (since you want to base this off of the efiv8) is the efiv8 source which netkas isn't currently making publicly available because he claims to have lost it.

netkas also isn't currently making the gfxutil source publicly available and I believe that much of it would be useful to your project and he might even be kind enough to provide it to you for this purpose.

The current status of many projects is that development of many projects are closed and are being based on specific peoples interest and precludes anyone who for whatever reason has different interests.

I for one have several machines running Tiger (which they do very well) and serve a specific purpose and am dumb-founded when people talk about openly developing software but refuse to make the source code available so openly developing really means that they are telling everyone they are developing something but the project is really closed to the general public.

It frustrates me that I am hindered by some hardware issue because the developer refuses to provide binaries for their software that runs in Tiger and refuses to make the source available so that those who wish to continue in their Tiger phase can do so.

If your going to work on it in an open environment then it should be open to anyone with an interest/desire, if your going to work on it in a closed environment then take the project behind closed doors and make announcements of your progress.

At a minimum, be willing to provide support for Tiger users to cater to all users and not just the select few who believe they are better because they're running Leo.