Slashdot Mirror
Domain: tianocore.org
Stories and comments across the archive that link to tianocore.org.
Comments · 8
-
Re:hmm
"You have never tried this have you?"
I'm typing on my Lenovo Yoga 2 running Fedora Core in Secure Boot mode . I have entered into the BIOS on literally thousand of computers installing all manner of hardware, have made custom BOISs, and have a working UEFI Virtual Machine that I built using source code from tianocore (UEFI Driver Developer Resources with EDK II), so I guess I'd have to say your guess was about as far off as humanly possible. If you had used your head you would have disabled secure boot prior to installing the 3rd party card, and then you would have been up and running in 2 minutes, unless of course you really care about Secure Boot, in which case your dog simple non-hack works just fine.
"If you add a third party wireless card to a Lenovo laptop, it fails the boot before it ever gets to the OS level. I had to take the card out and flash with a custom bios image and then put the card back.
So now you admit you didn't hack your BIOS? You simply flashed a version that had its signature in the database then? Right-o Steve! That's Grade A Ninja Hacking their Old Chum! (And yes, I've flashed hundreds of BIOS from many, many different vendors, and have known who AMI in the 1980's so I've been at this for a while)
For those with learning disabilities, those with Aspergers, and those with just generally poor scarcasm detectors, gmack did not perform any kind of "BIOS Hacking" as he originally claimed, and was merely doing something so simple a frigging monkey could follow the directions and do; and those directions might have been in IT for a very short while!
P.S. You still don't quite seem to grasp the original point I was making, which is your issue has absolutely nothing to do with DRM! Does it make more sense to you in bold italics? -
Re:what IS this?
like the Intel reference implementation on uefi.org
Are you referring to DUET of the Tianocore project? Others agree with you. It's shocking that every mainstream source is talking about this as black magic. To put it bluntly, it's an implementation of EFI that loads after the BIOS - something you can achieve in software for nothing.
-
Re:Some interesting possibilities open up.I know. I maintain the Freshmeat record for it and had to change the description and links after the changeover. I happen to think Coreboot is a crappy name and there's a risk that any positive associations people have with LinuxBIOS will get lost. Mind you, it's probably much more acceptable to suits and marketroids, who always disliked both the Linux association and the idea of an unwarrantied BIOS (not that any BIOS is actually under warranty, or that anyone has ever successfully sued a software company for a defective product). I guess it's also true that the name is more representative, as LinuxBIOS/Coreboot is more of a bootstrap than a BIOS. I still don't like it, though. Regardless of what you call it, though, it's a damn good program and, along with OpenBIOS, offers some really nice possibilities. Intel's Tiano shows no news activity since April 23rd of last year and most of the code repository looks largely untouched. A log entry of "initial import" for virtually all files is not terribly promising. Intel requires that it be used, though, which is amusing. Either they're holding back (well, it IS Intel, after all). or the Not Invented Here culture still overwhelms common sense (which, again, would be perfectly normal for Intel).
As another poster pointed out, the flash memory discussed is not in fact used for BIOSes, so my point there was flawed, but I think that this mini-thread was nonetheless worthwhile having.
-
Re:Why not EFI?
EFI is a specification, not an implementation, where the core pieces are still controlled (And _never_ opened up) by vendors and is usually still a big wad of real mode assembly that nobody wants to touch. There is no 100% open-source EFI-compliant BIOS implementation. The specification alone for EFI is over 1,000 pages.
To top it all off, to even begin development on stuff like Tianocore you need to agree to draconian licensing terms such as: "You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software." ( https://www.tianocore.org/nonav/servlets/LegalNotices?type=TermsOfService ).
So I guess your question is sort of like asking why people don't like to use proprietary drivers, even though there are some out there that work very well. The nice thing about Macs is that Apple seems to have went out of their way to make EFI invisible to the user. I don't trust that this will happen on most other pieces of hardware. The BIOS belongs out of the way, IMHO. -
Re:What about osdev?By jonwil (467024) The #1 reason I want something like EFI is to eliminate the world of proprietary bootloaders/selection mechanisms for good. Essentially the BIOS would be the one that displays the list of boot options.
Unfortunatly no vendor that supports EFI (including all Linux distros I have seen) gets it totally right (where any boot time configuration options are handled through EFI and not through another bootloader)
Well, EFI may not be the best way to get away from proprietary stuff. It seems that EFI explicitly vacilitates such behaviour by hardware manufacturers:
Interview with Ronald G. Minnich (Google cache) What are your thoughts on the Extensible Firmware Interface (EFI)?
I have spoken with the EFI authors at length. They make no secret of the fact that a "core value" of EFI is the preservation of intellectual property related to chipset programming and internal architecture. To put it another way, EFI is dedicated to the preservation of "Hard" hardware (as defined above), and the provision of binary interfaces and subsystems to BIOS vendors and others.
It is not really possible to build a full open-source BIOS if EFI is involved. The Tiano system, which Intel claims is an open source BIOS, can not be used to build a BIOS unless it is attached to proprietary, binary-only BIOS code provided by a vendor.
Another important thing to realize about EFI is that it also contemplates enabling chipset features that will trap certain OS operations to an EFI-based control system running in System Management Mode. In other words, under EFI, there is no guarantee that the OS owns the platform.
Accesses to IDE I/O addresses, or certain memory addresses, can be trapped to EFI code and potentially examined and modified or aborted. Many see this as an effort to build a "DRM BIOS".
I am not sure what the real intent of this design is, but is is a real concern in secure environments (such as those found in governments, banks, and large search engine companies). A number of vendors and users have told me that they are not sure they can ship an EFI system they are willing to trust in a secure environment. -
Re:Extensible Firmware Interface
uhhh: https://www.tianocore.org/nonav/servlets/LegalNot
i ces?type=TermsOfService
"You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software."
This is a compulsory licensing agreement which developers must agree to before even hopping on board with Tianocore. -
Update
Hello. Just to give a bit of an update on this issue...
The iMacs in question were rendered unbootable by trying to load additional modules from Intel's EFI Sample Implementation. It is not known which module is at fault currently.
Once the iMac is unbootable, it doesn't chime, boot, attempt to access media, or display an image on the screen. Attempts to zap NVRAM (cmd-opt-P-R is still supported for this task on Intel-based Macs), remove the motherboard battery and leave the AC power disconnected for an extended period of time, and disconnecting the hard disk do not resolve the issue.
At present, we seem to have a number of difficult situations that prevent the installation of Windows directly on Intel-based Macs:
1. Apple did not include its own EFI shell or other tools to access the EFI with the Intel-based Macs, so the tools used have consisted of Intel's EFI Sample Implementation, and Tianocore's EFI Developer Kit.
2. Apple's EFI implementation does not include CSM (Compatibility Support Module), the BIOS backward compatibility layer necessary for booting 32-bit versions of Windows (pre-Vista), such as Windows XP.
3. 32-bit versions of Windows do not currently support booting an EFI machine. (And the Gateway Media Center machine with EFI people keep talking about boots Windows XP Media Center Edition 2005 in BIOS compatibility mode, not with EFI.)
4. Windows XP 64-bit and Windows Server 2003 64-bit support EFI, but the Intel Core Duo is a 32-bit architecture.
5. Windows Vista does support EFI, but the EFI booter (cdboot.efi) currently does not appear to be functioning, and/or it is looking for, and not finding, information that it is looking for on the installation DVD. It does display the typical Windows "Please press any key to boot from the CD..." message. However, the DVD does not appear to contain the necessary EFI boot partition, and EFI does not support UDF volumes and El Torito booting. (Yes, this is a DVD obtained via official channels.)
6. Mac OS X's startup disk control panel presents a Windows Vista installation on a FAT/FAT32 volume as a valid bootable volume, but Windows Vista does not support booting from a FAT/FAT32 partition, only NTFS. Mac OS X can read NTFS volumes, but not write to them. This is currently the stage we're at now. No, I haven't tried "just hooking up a drive with Vista installed" (as many have asked elsewhere) or forcibly creating an NTFS partition whose contents are an already-installed instance of Vista.
7. grub, elilo, etc., all do not work on the Intel-based Macs at this time.
Eventually, whatever method boots Windows natively will have to have a nice wrapper put around it to make it easy for a normal person to do so, and easily dual boot in addition.
To regurgitate what I've said a bit elsewhere, the real benefit to most people will come from running Windows alongside Mac OS X in a "virtual machine" environment, in a window or even full screen, with, for example, a hotkey to switch back and forth between Mac OS X and Windows. To many users who prefer Mac OS X, particularly in enterprise, academic, and research environments, but who also have the occasional applications (usually administrative) that require Windows, this configuration would be a holy grail of sorts. And in this configuration, Windows wouldn't be running in emulation, but it would be running at essentially the native speed of the underlying hardware (with the exception of graphics and disk I/O performance). It will be *much* faster than any emulation ever has been, and there will no doubt be several open source (qemu, xen, wine) and commercial (vmware, Virtual PC) that will allow running Windows (or Windows software) in various capacities. Intel's Virtualization Technology (VT), allowing multiple operating systems to run in separate hardware "partitions" on one -
Best of all this will be Open Sourced by Intel!
The source code for Intel's implementation of EFI can be found at http://www.tianocore.org/
Also, this standard should finally allow seemless integration of new hardware onto the linux desktop. The main hurdle for desktop linux has always been lack of seemless driver integration.