Re: [edk2] minnowboard and duet

2014-02-06 Thread Blibbet
On 2/6/14 5:25 PM, Rod Smith wrote: > On 02/06/2014 03:36 PM, Blibbet wrote: >> >> If you really want to try and use DUET, look to external DUET extensions >> that make the TianoCore DUET release usable. There's this one, and one >> other I can't find at the moment: >> https://gitorious.org/tianoco

Re: [edk2] minnowboard and duet

2014-02-06 Thread Rod Smith
On 02/06/2014 03:36 PM, Blibbet wrote: > > If you really want to try and use DUET, look to external DUET extensions > that make the TianoCore DUET release usable. There's this one, and one > other I can't find at the moment: > https://gitorious.org/tianocore_uefi_duet_builds FWIW, I wrote a page o

Re: [edk2] minnowboard and duet

2014-02-06 Thread Richardson, Brian
I'll bug some EDK II maintainers about the OVMF updates. Thanks ... br --- Brian Richardson -- brian.richard...@intel.com -- Twitter: intel_brian -Original Message- From: Blibbet [mailto:blib...@gmail.com] Sent: Thursday, February 06, 2014 5:55 PM To: Richardson, Brian Cc: edk2-devel@lis

Re: [edk2] minnowboard and duet

2014-02-06 Thread Blibbet
EDK2's OVMFs were last updated 2011. They magically appeared on this subdirectory, as they're unmaintained. :-) I presume the only people who update these files are UEFI Forum members. The ones from the Linux community are circa 2013. It'd be nice if you uploaded fresh OVMFs when you upload new

Re: [edk2] Error compiling OVMF

2014-02-06 Thread Laszlo Ersek
On 02/06/14 23:04, Scott Duplichan wrote: > Laszlo Ersek [mailto:ler...@redhat.com] wrote: > > > ]On 02/05/14 20:28, Mauro Faccenda wrote: > ]> Hi all, > ]> > ]> When trying to compile OVMF in latest version it fails with the following > ]error: > ]> > ]> edk2\ovmfpkg\library\platformbdslib\qe

Re: [edk2] Error compiling OVMF

2014-02-06 Thread Scott Duplichan
Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]On 02/05/14 20:28, Mauro Faccenda wrote: ]> Hi all, ]> ]> When trying to compile OVMF in latest version it fails with the following ]error: ]> ]> edk2\ovmfpkg\library\platformbdslib\qemubootorder.c(888) : warning ]> C4701: potentially uninitializ

Re: [edk2] minnowboard and duet

2014-02-06 Thread Richardson, Brian
Minor quibble ... "The UEFI Forum doesn't bother to update OVMF binaries to their download site, they're ancient." The UEFI Forum doesn't maintain OVMF or EDK Ii in general. EDK II is written to UEFI specs, and companies that are members of the UEFI Forum work on the project, but it's not an off

Re: [edk2] minnowboard and duet

2014-02-06 Thread John Davis
Hello Bibbet, Thank you for the info. I appreciate it. FWIW, I was just curious what the package was as I was poking around. Speaking of opensource, here is a good video on UEFI and Android. Off camera you can hear Dong Wei from HP speaking a few times. I just happened to be listening to this

Re: [edk2] minnowboard and duet

2014-02-06 Thread Blibbet
Use QEMU/OVMF, it gets more attention from Intel than DUET, which was an older tech. I don't think anyone at ARM cares about DUET, but theydo care about helping QEMU/OVMF. The UEFI Forum doesn't bother to update OVMF binaries to their download site, they're ancient. They presume you'll use the

Re: [edk2] minnowboard and duet

2014-02-06 Thread Jarlstrom, Laurie
Hi John, First for the MinnowBoard. Yes, the firmware is EDK II based and is basically based on the UDK2010.SR1.UP1.P1 release. I will make a cross link on the tianocore.org web pages but the link to get the board is : http://Minnowboard.org and the link to download the source is : http://uef

[edk2] minnowboard and duet

2014-02-06 Thread John Davis
Hello As I am looking through the EDKII workspace, I am wondering where is the port for minnowboard? I saw a video from an Intel guy on youtube and it mentioned the minnowboard as a atom based board which could be used as a cheap UEFI reference development kit. This sounds like a good deal for th

Re: [edk2] [PATCH] Clean up hard-coded offsets and other utter bogosity in Thunk16.S.

2014-02-06 Thread Sergey Isakov
Hi David, The THunk16.S is wrong again. 1. I see you excluded .byte 66 and this leads to wrong codes: see dissassembled output: ——— 003a 16 pushss ^ │003b 0e pushcs