mailing list. I
realized after sending.
>
> > From: qemu-devel-bounces+andrew.baumann=microsoft@nongnu.org
> > [mailto:qemu-devel-
> > bounces+andrew.baumann=microsoft....@nongnu.org] On Behalf Of Piotr
> > Król
> > Sent: Wednesday, 30 December 2015 17:14
>
c
> create mode 100644 hw/intc/bcm2836_control.c
> create mode 100644 hw/misc/bcm2835_mbox.c
> create mode 100644 hw/misc/bcm2835_property.c
> create mode 100644 include/hw/arm/bcm2835_peripherals.h
> create mode 100644 include/hw/arm/bcm2836.h
> create mode 100644 include/h
On Fri, Aug 15, 2014 at 11:54:55PM +0100, Peter Maydell wrote:
> I'm not looking for advocacy, just for an explanation of what it's
> doing, and in particular whether anybody's ever tested this on real
> hardware. (Running guest code only on QEMU is a recipe for bugs,
> because our emulation is oft
.1 shipped), so 0 is always flash
> and never RAM. This is consistent but (as you've
> found) binaries assuming that 0 is a RAM alias
> will stop working.
>
Assuming option (2) contain strategy for future releases it should be
priority. I will try to fix coreboot binary according to this advice.
One more time thanks for explanation.
Thanks,
Piotr Król
Hi all,
I'm trying to boot latest coreboot on qemu-system-arm (-M vexpress-a9).
I compiled qemu arm-softmmu from source (latest code) and trying to boot
with:
qemu-system-arm -M vexpress-a9 -m 1024M -nographic -bios build/coreboot.rom
First of all mtree looks strange because there are two aliases
