(+ Leif)
Exec summary: strange QEMU bug triggered by RELEASE_GCC5 code, which
is caused by a spurious write to the NOR flash at runtime. The latter
is also a bug, in Tianocore.
On 18 August 2016 at 16:36, Peter Maydell wrote:
> On 18 August 2016 at 15:15, Ard Biesheuvel wrote:
>> On 18 August 2
On 18 August 2016 at 15:15, Ard Biesheuvel wrote:
> On 18 August 2016 at 16:10, Peter Maydell wrote:
>> On 16 August 2016 at 13:08, Ard Biesheuvel wrote:
>>> Bad ram pointer 0x54
>>> Aborted (core dumped)
>>
>> So the reason this happens is that get_page_addr_code() doesn't
>> correctly handle t
On 16 August 2016 at 13:08, Ard Biesheuvel wrote:
> Bad ram pointer 0x54
> Aborted (core dumped)
So the reason this happens is that get_page_addr_code() doesn't
correctly handle the case of the memory region being a
ROM that's not in ROMD mode. That is, the flash memory can
be either in "reads ma
On 18 August 2016 at 16:10, Peter Maydell wrote:
> On 16 August 2016 at 13:08, Ard Biesheuvel wrote:
>> Bad ram pointer 0x54
>> Aborted (core dumped)
>
> So the reason this happens is that get_page_addr_code() doesn't
> correctly handle the case of the memory region being a
> ROM that's not in RO
On 18 August 2016 at 12:40, Peter Maydell wrote:
> On 16 August 2016 at 13:08, Ard Biesheuvel wrote:
>> I am hitting this strange issue when executing the UEFI firmware for
>> QEMU mach-virt/AArch64. This only occurs when building the firmware
>> with GCC5 in RELEASE mode, but the failure mode su
On 16 August 2016 at 13:08, Ard Biesheuvel wrote:
> I am hitting this strange issue when executing the UEFI firmware for
> QEMU mach-virt/AArch64. This only occurs when building the firmware
> with GCC5 in RELEASE mode, but the failure mode suggests that this may
> not be relevant.
Yeah, we shoul
