Hi,
The open-source version working with most all embedded HDA sound is here
https://gitorious.org/freebsd/freebsd/source/3a99e974a21798784a5943bec4dfa5f3960de443:sys/dev/sound/pci/hda/hdac.c
Sergey
On 07 нояб. 2013 г., at 19:57, Andrew Fish wrote:
>
> On Nov 7, 2013, at 4:01 AM, Rafael Machad
Hi Micheal and Chiran,Current UEFI image size which is built for Gauss is 760KB and I don't think it will be exceed 2MB even more features included in the UEFI for Laplace.So I assume that the UEFI image can be stored in the SPI and loaded by SCP upon request of Atlas BL1.That's the only option for
On 11/08/13 19:04, Jordan Justen wrote:
> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
>> I also wanted to test secure boot (see if the enrolled keys survive a
>> cold reboot), but I noticed that this series doesn't disable the "load
>> variables from the NvVars file" functionality.
>>
>>
On Fri, Nov 8, 2013 at 11:23 AM, Andrew Fish wrote:
>
> On Nov 8, 2013, at 11:10 AM, Jordan Justen wrote:
>
>> On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek wrote:
>>> On 11/08/13 19:04, Jordan Justen wrote:
On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
> I also wanted to test s
On Nov 8, 2013, at 11:10 AM, Jordan Justen wrote:
> On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek wrote:
>> On 11/08/13 19:04, Jordan Justen wrote:
>>> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
I also wanted to test secure boot (see if the enrolled keys survive a
cold rebo
On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek wrote:
> On 11/08/13 19:04, Jordan Justen wrote:
>> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
>>> I also wanted to test secure boot (see if the enrolled keys survive a
>>> cold reboot), but I noticed that this series doesn't disable the "lo
On Fri, Nov 08, 2013 at 01:25:34PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 08, 2013 at 05:49:39PM +, Wei Liu wrote:
> > The original code calculates the start of PCI MMIO region automatically,
> > which is not desirable when running under Xen, as Xen is responsible of
> > setting up r
On Wed, Oct 30, 2013 at 5:51 PM, Laszlo Ersek wrote:
> On 10/31/13 00:26, Jordan Justen wrote:
>
>>> Jordan, could you please explain the problem again?
>>
>> This protocol interface doesn't seem to follow the conventions of the
>> other io protocols. In addition, the alignment issue seems unresol
On 11/08/13 19:04, Jordan Justen wrote:
> On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
>> I also wanted to test secure boot (see if the enrolled keys survive a
>> cold reboot), but I noticed that this series doesn't disable the "load
>> variables from the NvVars file" functionality.
>>
>>
On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek wrote:
> I also wanted to test secure boot (see if the enrolled keys survive a
> cold reboot), but I noticed that this series doesn't disable the "load
> variables from the NvVars file" functionality.
>
> I added the attached patch on top of this serie
The original code calculates the start of PCI MMIO region automatically,
which is not desirable when running under Xen, as Xen is responsible of
setting up respective regions.
This patch makes it possible to specify start of PCI MMIO so OVMF can
honor the region set up by Xen.
Contributed-under:
Il 08/11/2013 16:08, Marcel Apfelbaum ha scritto:
> Actually, as I see, the default behavior of "system" memory region
> is to use unassigned_mem_ops that has valid.accepts method returning
> false (no read/write methods). I don't see that read all-ones/ignore
> writes is implemented.
Right, it's
On 11/08/13 16:16, Peter Maydell wrote:
> On 8 November 2013 15:07, Laszlo Ersek wrote:
>> On 11/08/13 07:09, Jordan Justen wrote:
>>> int64_t? :)
>>
>> Heh, yes, I did cringe when I wrote that, but if you check the
>> bottom-most function, where the assignment happens,
>> pc_system_flash_init(),
On 11/08/13 07:09, Jordan Justen wrote:
> On Thu, Nov 7, 2013 at 2:23 PM, Laszlo Ersek wrote:
>> ... upwards through the following call chain:
>>
>> pc_init1() | pc_q35_init()
>> pc_memory_init()
>> pc_system_firmware_init()
>> pc_system_flash_init()
>>
>> Signed-off-by: Laszlo
Il 08/11/2013 11:44, Peter Maydell ha scritto:
> On 8 November 2013 08:05, Paolo Bonzini wrote:
>> Il 07/11/2013 22:51, Peter Maydell ha scritto:
> 1. Not all architectures have the behavior: "Address space that is not
> RAM(and friends)
> is for sure PCI". Only x86 behaves like t
Il 07/11/2013 23:23, Laszlo Ersek ha scritto:
> On 11/07/13 22:24, Marcel Apfelbaum wrote:
>> Why pci-hole and system.flash collide? IMHO we should not play with
>> priorities here, better solve the collision.
>
> What about this "beautiful" series? It produces
>
> memory
> -000ff
Il 07/11/2013 22:51, Peter Maydell ha scritto:
>> > 1. Not all architectures have the behavior: "Address space that is not
>> > RAM(and friends)
>> > is for sure PCI". Only x86 behaves like this (I think).
>
> More specifically, the x86 pc behaves like this. Other
> x86 based systems could in
17 matches
Mail list logo
