Dear all,
After EDK2 rev:14820
MdeModulePkg Pool: Update the type of Size to UINTN for the potential more
than 4GB buffer allocation.
It modify the POOL_HEAD structure in MdeModulePkg\Core\Dxe\Mem\Pool.c,
however it doesn't sync to the POOL_HEAD structure in
StdLib\LibC\StdLib\Mallo
On 02/04/14 02:23, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
> walk into mine at 15:55:00 on Monday 03 February 2014 and say:
>
>> On 02/04/14 00:05, Bill Paul wrote:
>>> Of all the gin joints in all the towns in all the world, Laszlo Ersek ha
Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 15:55:00 on Monday 03 February 2014 and say:
> On 02/04/14 00:05, Bill Paul wrote:
> > Of all the gin joints in all the towns in all the world, Laszlo Ersek had
> > to
> >
> > walk into mine at 14:36:0
On 02/04/14 00:05, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
> walk into mine at 14:36:03 on Monday 03 February 2014 and say:
>
>> On 02/03/14 23:02, Bill Paul wrote:
>>> For the most part this works fine, but I noticed that when I build OVMF
On Feb 3, 2014, at 3:05 PM, Bill Paul wrote:
> It triggers for me with X64 builds too. I'm pretty sure unsigned long is
> always 32 bits.
The size of long varies across the compilers used in the edk2 project for X64.
VC++ is LLP64 and some of the Unix compilers are LP64.
Thanks,
Andrew Fi
John,
Here is some information about EADK, StdLib, and the old EDK Toolkit.
The EDK Toolkit is no longer supported and is not for EDK II.
Most of the functionality from the EDK Toolkit has been added to EDK II, but
not necessarily as part of a monolithic chunk. Some of the functionality was
m
Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 14:36:03 on Monday 03 February 2014 and say:
> On 02/03/14 23:02, Bill Paul wrote:
> > Since I'm building on FreeBSD, I'm using the generic UNIX instructions
> > for building with the EDK2. This means I
On 02/03/14 23:02, Bill Paul wrote:
> Since I'm building on FreeBSD, I'm using the generic UNIX instructions for
> building with the EDK2. This means I'm using the cross-compiler tools
> generated by the mingw-gcc-build.py script.
(BaseTools/gcc/README.txt seems to imply that the output of these
Since I'm building on FreeBSD, I'm using the generic UNIX instructions for
building with the EDK2. This means I'm using the cross-compiler tools
generated by the mingw-gcc-build.py script.
For the most part this works fine, but I noticed that when I build OVMF, I see
the following warnings:
ed
Hi again,
As suggested by Leroy Leahy I've trim down the code to isolate the
problem and is available as a package here:
https://dl.dropboxusercontent.com/u/6173306/TestPkg.zip
I already exchanged some messages with him but I couldn't make it work
yet. He isn't available for now, that's why I am
Hi,
> QemuVideoBochsModeSetup()
> Avail = BochsRead(VBE_DISPI_INDEX_VIDEO_MEMORY_64K) // just grab
> // it here
> /* filter & populate modes */
Yes, with BochsRead being an external function (/me didn't check) tha
On 02/03/14 09:40, Gerd Hoffmann wrote:
> Hi,
>
>> But, indeed, that's my problem exactly. I did look into the qemu source
>> (and I did notice VBE_DISPI_INDEX_VIDEO_MEMORY_64K), and there are about
>> five device and/or global properties (from which libvirt uses at least
>> two) that mess aroun
Hi,
> But, indeed, that's my problem exactly. I did look into the qemu source
> (and I did notice VBE_DISPI_INDEX_VIDEO_MEMORY_64K), and there are about
> five device and/or global properties (from which libvirt uses at least
> two) that mess around with sizes related to video ram.
ram_size
On 02/01/14 22:36, Paolo Bonzini wrote:
> Il 29/01/2014 00:10, Laszlo Ersek ha scritto:
>> Please note though that OVMF code to actually honor this setting will
>> only be written/added once the "basic" S3 functionality is complete.
>> (Which it is not, for the time being.)
>>
>> Naturally, you can
On 02/03/14 08:37, Gerd Hoffmann wrote:
> On Fr, 2014-01-31 at 21:05 +0100, Laszlo Ersek wrote:
>> In the next patch we'll add many new BOCHS modes, some of which require
>> large frame buffers.
>>
>> The size of the primary bar (frame buffer) can be changed with the
>>
>> -global qxl-vga.ram_siz
15 matches
Mail list logo
