On 31 May 2018 at 12:48, Jason A. Donenfeld wrote:
> On Thu, May 31, 2018 at 10:32 AM, Peter Maydell
> wrote:
>> It stalled on the fact that adding the second UART breaks
>> UEFI images (annoyingly, UEFI iterates through UARTs in
>> the DTB in the opposite direction to Linux, so if you add
>> a
On Thu, May 31, 2018 at 10:32 AM, Peter Maydell
wrote:
> It stalled on the fact that adding the second UART breaks
> UEFI images (annoyingly, UEFI iterates through UARTs in
> the DTB in the opposite direction to Linux, so if you add
> a second UART then it picks that one to use rather than
> the
On 31 May 2018 at 03:12, Jason A. Donenfeld wrote:
> Hi Peter,
>
> What ever became of this? I still really could use a second UART in
> the standard configuration. I'm still building with this cludge --
> https://א.cc/RXI3ssWV -- in order to run the test suite on
> build.wireguard.com.
It
Hi Peter,
What ever became of this? I still really could use a second UART in
the standard configuration. I'm still building with this cludge --
https://א.cc/RXI3ssWV -- in order to run the test suite on
build.wireguard.com.
Thanks,
Jason
On 12 December 2017 at 15:16, Andrew Jones wrote:
> OK, so this patch is fine, but it kills my suggestion for AAVMF to
> only output debug messages to a debug port when the debug port is
> actually useful. Now it won't be able to tell the difference unless
> we can inform it
On Fri, Dec 08, 2017 at 03:02:07PM +, Peter Maydell wrote:
> Currently we only provide one non-secure UART on the virt
> board. This is OK for most purposes, but there are some
> use cases where having a second UART would be useful (like
> bare-metal testing where you don't really want to have
On Tue, Dec 12, 2017 at 02:50:50PM +, Peter Maydell wrote:
> On 12 December 2017 at 14:45, Andrew Jones wrote:
> > Should this be
> >
> > if (!vmc->no_second_uart && serial_hds[uart_count] != NULL) {
> >
> > A bit late now, but maybe the other UART resource allocations
On 12 December 2017 at 14:45, Andrew Jones wrote:
> Should this be
>
> if (!vmc->no_second_uart && serial_hds[uart_count] != NULL) {
>
> A bit late now, but maybe the other UART resource allocations should have
> been conditional on actually being wired up too?
What does
On Fri, Dec 08, 2017 at 03:02:07PM +, Peter Maydell wrote:
> Currently we only provide one non-secure UART on the virt
> board. This is OK for most purposes, but there are some
> use cases where having a second UART would be useful (like
> bare-metal testing where you don't really want to have
In case it's of direct interest in this thread, the ARM results on
https://www.wireguard.com/build-status/ are running on a QEMU built
with this disgusting cludge: https://א.cc/roJ0gMw3
The patch of this thread is the actually correct way of accomplishing
what that cludge does.
On 12 December 2017 at 05:55, Shannon Zhao wrote:
> On 2017/12/8 23:02, Peter Maydell wrote:
>> Currently we only provide one non-secure UART on the virt
>> board. This is OK for most purposes, but there are some
>> use cases where having a second UART would be useful
On 2017/12/8 23:02, Peter Maydell wrote:
> Currently we only provide one non-secure UART on the virt
> board. This is OK for most purposes, but there are some
> use cases where having a second UART would be useful (like
> bare-metal testing where you don't really want to have to
> probe and set
Currently we only provide one non-secure UART on the virt
board. This is OK for most purposes, but there are some
use cases where having a second UART would be useful (like
bare-metal testing where you don't really want to have to
probe and set up a PCI device just to have a second comms
channel).
13 matches
Mail list logo