Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 08:31:22 on Wednesday 12 February 2014 and say:
> On 02/12/14 01:51, Bill Paul wrote:
> > the
> > fact that the QEMU/OVMF combo doesn't actually emulate a persistent flash
> > device.
>
> Use
> - qemu-1.6+, and
Just compiled and installed 1.6.2 fresh from source.
> - Linux host kernel 3.7+ (for KVM support) *or* TCG, and
I'm on FreeBSD, not Linux, and CPU acceleration isn't really a priority. This
is not a droid that I'm looking for.
> - a fresh OVMF, and
Just did an SVN checkout and built with secure boot support and 2MB image as
usual.
> - pass OVMF.fd with the -pflash option instead of the -bios option.
>
> Then the first 128KB of the OVMF.fd file will function as non-volatile
> variable store. (The size of the area that is directly available for
> variables is 56KB.)
>
> This is also described in the README file (search for -pflash).
>
> Note that OVMF may reorder your boot options (change the BootOrder
> variable) if you pass any boot order specification to qemu, either with
> the -boot option, or with the "bootindex" property of any device
> (-device XXXX,bootindex=N option).
I'm not using those options.
The -pflash flash does seem to work.
However there seems to be some sanity checking going somewhere with OVMF that
doesn't occur with the real hardware that I've bricked:
- If I use a version of my loader to create a correctly formatted BootXXXX
variable -- in this case Boot0006 -- and add it to the head of the BootOrder,
it's properly preserved across QEMU instances.
- If I run the buggy version of the loader and create a bogusly formatted
BootXXXX variable and add it to the head of the BootOrder, it gets removed
somewhere along the line -- if I reset the emulator and hit a key to interrupt
the boot process and go to the shell and use dmpstore -b Boot*, I can see that
the Boot0006 variable has been deleted from the datastore and the BootOrder
variable has been updated as well.
I'm not exactly sure what code/module is responsible for doing this (Bds?),
but clearly something is chucking the bad boot path variable out the window.
My suspicion is that the code on the hardware that I have is just older and
not as good about validating the boot paths, and unfortunately that creates a
dangerous situation.
Also, I don't believe the UI itself is an issue (as suggested by an earlier
post). With the failures I've experienced, the UI itself is not the problem:
the machines make it to the UI in the first place.
Unfortunately, the one casualty is my tablet, which I don't think I can
recover without either major surgery or extreme cleverness. I tried unplugging
the internal SSD drive but that failed to wake it up. If I could find the
flash chip then maybe I could strobe the chip select pin at just the right
time to make it fail to read the stored variables I think I might be able to
unjam it, although that might be very tricky if the same chip is used to store
the firmware and the variables. But that's an experiment for another day.
-Bill
> Laszlo
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
[email protected] | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
