Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 10:57:25 on Tuesday 28 January 2014 and say:
> On 01/28/14 19:28, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Laszlo Ersek had
> > to
>
> > walk into mine at 04:07:29 on Tuesday 28 January 2014 and say:
> I think I've never tried gin. I like beer and various liqueurs. Based on
> the wikipedia entry for gin, I'm adding gin to my TODO list. Thanks.
I actually don't partake myself, but this header has a long tradition going
back over 20 years now, so I'm not about to change it. :)
> >> On 01/27/14 23:01, Bill Paul wrote:
> >>
> >> Placing this string of areas at 0x800000 is quite arbitrary for us, as
> >> far as I know. I believe (without doing any investigation) that we could
> >> move it a bit around, but it must stay low. The decompression happens at
> >> an early stage.
> >
> > Can't you move it after decompression?
>
> IMO it wouldn't be too practical. By the time we could conveniently move
> it around, we'd be *running* from it already. So if we end up putting it
> elsewhere, we should do that off the bat.
>
> Of course Jordan might have a different opinion.
I think part of my problem is that I don't quite understand how the firmware
image volumes work either. You start out with one OVMF.fd image, which
contains all of the firmware in compressed form. I'm assuming this image is
mapped by QEMU into the address space such that there's some initial bootstrap
code placed at the reset vector so that the CPU hits it at power-up/reset, and
from there it extracts the contents into RAM.
What I don't know is just where everything ends up in RAM. You have sections
marked BS_Code, BS_Date, RT_Code, RT_Data and LoaderCode. Is LoaderCode the
guts of the firmware? Are you saying the PEIFV area contains yet more guts?
And that at the time you have to decide where to put it, you don't know how
much RAM is available yet and/or the code isn't relocatable?
> >> Why does it bother you where it is right now? What conflict do you see?
> >
> > What I'm doing is running VxWorks in QEMU for testing purposes. Using
> > QEMU and OVMF has proven to be an excellent way to experiment with
> > booting VxWorks with UEFI before moving to real hardware.
>
> Awesome! It's one of the (semi-)stated goals with OVMF in my
> understanding (ie. support development of runtime OS's UEFI-related
> parts), and it's nice to see OVMF being put to use.
The funny thing is that Intel/Wind River also has Simics. Like, we literally
have it (we acquired them). However I started using QEMU a while ago and while
Simics is more flexible, QEMU is simpler (and runs on FreeBSD :P ). I don't
know if there's a Simics model that supports IA+UEFI. (I've actually only used
it for PPC models.)
> > The problem I'm having has to do with VxWorks' memory management. Due to
> > hysterical raisins, when the VxWorks kernel starts up, it expects to be
> > given a contiguous chunk of memory to use as its initial heap memory
> > pool. Once the kernel is running you can add additional chunks -- these
> > are called memory partitions by the memory manager.
> >
> > The thing is, on the Intel arch, it's always been assumed that that the
> > first chunk of usable memory starts at 0x100000 and is fairly large.
> > With the memory hole created by the PEIFV block, you end up with only
> > about 7MB in this block, which is too small. (The real havoc occurs with
> > 64-bit VxWorks, which has additional restrictions.)
>
> I hope you too perceive how hilarious this is :) The reasons you listed
> for VxWorks mostly hold for OVMF too (= "we're just starting so let's
> stick with something very low until we know more about the system").
>
> How large a contiguous range would you need from 1MB upwards? (Because
> the address that we'd shift this up to would likely directly impact the
> minimum qemu guest memory requirements.)
Unfortunately I'm not sure I have a good answer to that question. We typically
load the VxWorks image at 0x408000, and I think out of the box the 32-bit
build needs about 300MB. (Yes, I know: that doesn't sound very embedded, does
it.)
But I don't think this is the right way to approach the issue either.
Something tells me there's a better way to do what you're trying to do, but I
don't understand enough about the problem yet to offer an alternate solution.
> > It is possible to tweak things in VxWorks to avoid this problem, but it's
> > a pain. It's also not something we typically encounter on real hardware.
>
> I don't think we'd like to hard-wire a *very* different base address
> statically. Maybe we could add a build option, but that only moves the
> pain around.
>
> Re it being different from real hardware, the explanation is that most
> of OVMF's modules are stored compressed in the flash, and are
> decompressed to (and then run from) RAM at startup. I assume on real
> hardware the firmware simply runs from flash. (Hm, I guess it could be
> shadowed into RAM too, but I have no data about what addresses.)
I think it equally likely that you'd have compressed flash images on real
hardware too. (We actually offer a romCompressed option with VxWorks, where
there's no firmware on the system: there's just VxWorks, and it disgorges
itself into RAM to execute. There is also a romResident option if you have
enough flash/ROM to hold the whole image and don't mind the performance hit.)
But if it's a question of just having the executable code still around
somewhere and you can't manage that with compressed images, why not create an
uncompressed build option too? Yes I know it would take up some more address
space, but that may be the only way to make it work.
> >> Additionally, after the full S3 support series committed, further code
> >> will be added to honor the case when the user disables S3 on the qemu
> >> command line ("-global PIIX4_PM.disable_s3=1"). Then the memory
> >> allocation in question will be qualified as Boot Services Data (rather
> >> than ACPI NVS), and the OS will be able to drop it after transitioning
> >> to runtime.
> >
> > It appears I need a newer version of QEMU for that option:
> >
> > root@core:/home/wpaul/ovmf # qemu-system-x86_64 -global
> > PIIX4_PM.disable_s3=1 qemu-system-x86_64: Property '.disable_s3' not
> > found
>
> Correct. This property was added in
>
> commit 459ae5ea5ad682c2b3220beb244d4102c1a4e332
> Author: Gleb Natapov <g...@redhat.com>
> Date: Mon Jun 4 14:31:55 2012 +0300
>
> Add PIIX4 properties to control PM system states.
>
> first released in v1.2.0.
>
> I searched the FreeBSD ports repo for qemu, and it seems that the
> "qemu-devel" package is at 1.7.0. (Not sure if you can easily get it in
> 9.1-RELEASE.)
I'm sure I can shoehorn it in somehow. :)
> > That aside, this would be an acceptable compromise, at least until
> > VxWorks supports S3 resume on the Intel architecture. :)
> >
> > I still think the placement of the PEIFV block is much less than ideal,
> > but for the time being I can deal with it.
>
> Alternatively, please propose the lowest address that would work out of
> the box for your use case, and then Jordan could decide if it was
> reasonable to re-wire the FDFs with that address.
I don't think assuming 300MB of RAM is reasonable so I don't think that will
work. Maybe once I've read more of the code I can suggest a better idea.
-Bill
> Thanks!
> Laszlo
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
