qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support
Date: Tue, 2 Feb 2016 17:01:03 +0000

On 28 January 2016 at 19:22, Jean-Christophe DUBOIS <address@hidden> wrote:
> Sabrelite uses uart2 for console but on qemu, this is uart1 that is wired to
> the default stdout. Consequently, I changed stdout-path in "chosen" to
> uart1.

This I find a bit awkward: we'd like to get eventually to the point
where you can run the stock device tree unedited. The other items
on your list are just "we don't emulate something yet", so the path
forward is to (eventually) emulate the missing things. But it's not
clear to me what we need to do to be able to stop editing stdout-path
in the future.

Perhaps the answer is just to use QEMU command line arguments to make
stdout be the uart2 rather than uart1?

> For now i.MX6 SOC code does not emulate SPI controller. During the boot
> Linux was getting stuck trying to access a SPI device that is supposed to be
> there. Therefore I disabled the SPI controller in the device tree.

This is OK for now, though I guess it means the SPI controller is
worth emulating to at least some extent.

> The sabrelite is supposed to have a bunch of push buttons (home, power,
> back, vol up, vol down) wired to various GPIOs. I guess these buttons might
> have pull up or pull down resistors on the real hardware but obviously on
> qemu we have no such things. As a results the GPIOs were triggering a lot of
> interrupts for nothing. So I commented out the GPIO sections were the
> buttons were defined.

This is OK for now, though it would be nice to wire all the GPIOs to 0 or
something if that helps avoid the problem without editing the DT.

thanks
--- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]