* Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
@ 2023-03-17 13:13 Abhishek Singh Dagur
2023-03-17 16:06 ` Alex Bennée
0 siblings, 1 reply; 7+ messages in thread
From: Abhishek Singh Dagur @ 2023-03-17 13:13 UTC (permalink / raw)
To: openbmc; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
Hi all,
We are using obmc-phosphor-image on an ast2500 board which is trying to
communicate with other devices over serial port /dev/ttyS2.
As we are trying to emulate the machine on qemu we need to redirect the
request to the host machine so that it can handle this request and return
appropriately.
We tried using QEMU options like -serial ,-chardev but still not the
concrete way we get to do it.
It will be very helpful if you can provide us some guidance on this.
Thank you,
Abhishek
[-- Attachment #2: Type: text/html, Size: 620 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-17 13:13 Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine Abhishek Singh Dagur
@ 2023-03-17 16:06 ` Alex Bennée
2023-03-17 17:24 ` Cédric Le Goater
0 siblings, 1 reply; 7+ messages in thread
From: Alex Bennée @ 2023-03-17 16:06 UTC (permalink / raw)
To: Abhishek Singh Dagur
Cc: openbmc, qemu-devel, Mark Cave-Ayland, Cédric Le Goater,
Peter Maydell
Abhishek Singh Dagur <abhishek@drut.io> writes:
(cc aspeed maintainers)
> Hi all,
>
> We are using obmc-phosphor-image on an ast2500 board which is trying to communicate with other devices
> over serial port /dev/ttyS2.
> As we are trying to emulate the machine on qemu we need to redirect the request to the host machine so
> that it can handle this request and return appropriately.
> We tried using QEMU options like -serial ,-chardev but still not the
> concrete way we get to do it.
Yeah I'm afraid its non-obvious, certainly for built in serial ports.
Try something like:
./qemu-system-aarch64 -M ast2500-evb \
-serial null -serial null -serial chardev:myserial \
-chardev file,id=myserial,path=output.txt \
$MORE_OPTIONS
You have to add a -serial for each serial port up to the one you care
about and then set the chardev for it.
If you where adding a device to the system then you can explicitly set
the target chardev for it with something like:
-device isa-serial,iobase=nnn,irq=nnn,chardev=ID
> It will be very helpful if you can provide us some guidance on this.
Another quirk for the aspeed boards seems to be the default uart can be
an arbitrary one depending on the board model:
334: aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
336: if (uart == amc->uart_default) {
1112: amc->uart_default = ASPEED_DEV_UART5;
1407: amc->uart_default = ASPEED_DEV_UART1;
as a result ASPEED_DEV_UART5 will always be the first serial port
(serial_hd(0)). I don't know how Linux numbers them but worth being
aware of.
>
> Thank you,
> Abhishek
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-17 16:06 ` Alex Bennée
@ 2023-03-17 17:24 ` Cédric Le Goater
2023-03-17 17:40 ` Abhishek Singh Dagur
2023-03-18 17:55 ` Abhishek Singh Dagur
0 siblings, 2 replies; 7+ messages in thread
From: Cédric Le Goater @ 2023-03-17 17:24 UTC (permalink / raw)
To: Alex Bennée, Abhishek Singh Dagur
Cc: openbmc, qemu-devel, Mark Cave-Ayland, Peter Maydell
On 3/17/23 17:06, Alex Bennée wrote:
>
> Abhishek Singh Dagur <abhishek@drut.io> writes:
>
> (cc aspeed maintainers)
>
>> Hi all,
>>
>> We are using obmc-phosphor-image on an ast2500 board which is trying to communicate with other devices
>> over serial port /dev/ttyS2.
>> As we are trying to emulate the machine on qemu we need to redirect the request to the host machine so
>> that it can handle this request and return appropriately.
>> We tried using QEMU options like -serial ,-chardev but still not the
>> concrete way we get to do it.
>
> Yeah I'm afraid its non-obvious, certainly for built in serial ports.
> Try something like:
>
> ./qemu-system-aarch64 -M ast2500-evb \
> -serial null -serial null -serial chardev:myserial \
> -chardev file,id=myserial,path=output.txt \
> $MORE_OPTIONS
>
> You have to add a -serial for each serial port up to the one you care
> about and then set the chardev for it.
>
> If you where adding a device to the system then you can explicitly set
> the target chardev for it with something like:
>
> -device isa-serial,iobase=nnn,irq=nnn,chardev=ID
>
>> It will be very helpful if you can provide us some guidance on this.
>
> Another quirk for the aspeed boards seems to be the default uart can be
> an arbitrary one depending on the board model:
>
> 334: aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
> 336: if (uart == amc->uart_default) {
> 1112: amc->uart_default = ASPEED_DEV_UART5;
> 1407: amc->uart_default = ASPEED_DEV_UART1;
>
> as a result ASPEED_DEV_UART5 will always be the first serial port
> (serial_hd(0)). I don't know how Linux numbers them but worth being
> aware of.
Yes. UART5 is the general default but it depends on the board definition
and the fuji was the first to require an exception. See commit 5d63d0c76c
("hw/arm/aspeed: Allow machine to set UART default")
Then, it became more complex with commit d2b3eaefb4 ("aspeed: Refactor
UART init for multi-SoC machines"). That's another topic.
Abhishek,
I am afraid, you will need to add a new board to fit what's in the DT.
Or, here is a little patch adding a machine option to set the default uart.
It was never merged because it is a bit of hack, give it a try and we
will discuss. Use :
-M ast2500-evb,uart-default=uart2
Thanks,
C.
From 0d0700ae772fa5236914e96af1be5afcf0d4a994 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
Date: Fri, 17 Mar 2023 18:21:54 +0100
Subject: [PATCH] aspeed: Add a "uart-default" machine option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
hw/arm/aspeed.c | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 806bb10707..e0335cf167 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -45,6 +45,7 @@ struct AspeedMachineState {
bool mmio_exec;
char *fmc_model;
char *spi_model;
+ uint32_t uart_default;
uint32_t hw_strap1;
};
@@ -337,10 +338,11 @@ static void connect_serial_hds_to_uarts(AspeedMachineState *bmc)
AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(bmc);
AspeedSoCState *s = &bmc->soc;
AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
+ int uart_default = bmc->uart_default ? bmc->uart_default : amc->uart_default;
- aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
+ aspeed_soc_uart_set_chr(s, uart_default, serial_hd(0));
for (int i = 1, uart = ASPEED_DEV_UART1; i < sc->uarts_num; i++, uart++) {
- if (uart == amc->uart_default) {
+ if (uart == uart_default) {
continue;
}
aspeed_soc_uart_set_chr(s, uart, serial_hd(i));
@@ -1145,6 +1147,25 @@ static void aspeed_set_spi_model(Object *obj, const char *value, Error **errp)
bmc->spi_model = g_strdup(value);
}
+const QEnumLookup UartDefault_lookup = {
+ .array =
+ (const char *const[]) {
+ [0] = "none",
+ [1] = "uart1",
+ [2] = "uart2",
+ [3] = "uart3",
+ [4] = "uart4",
+ [5] = "uart5",
+ },
+ .size = 6
+};
+
+static void aspeed_set_uart_default(Object *obj, int val, Error **err)
+{
+ AspeedMachineState *bmc = ASPEED_MACHINE(obj);
+ bmc->uart_default = val + 1;
+}
+
static void aspeed_machine_class_props_init(ObjectClass *oc)
{
object_class_property_add_bool(oc, "execute-in-place",
@@ -1153,6 +1174,12 @@ static void aspeed_machine_class_props_init(ObjectClass *oc)
object_class_property_set_description(oc, "execute-in-place",
"boot directly from CE0 flash device");
+ object_class_property_add_enum(oc, "uart-default", "UartDefault",
+ &UartDefault_lookup, NULL,
+ aspeed_set_uart_default);
+ object_class_property_set_description(oc, "uart-default",
+ "Change the default UART of the board");
+
object_class_property_add_str(oc, "fmc-model", aspeed_get_fmc_model,
aspeed_set_fmc_model);
object_class_property_set_description(oc, "fmc-model",
--
2.39.2
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-17 17:24 ` Cédric Le Goater
@ 2023-03-17 17:40 ` Abhishek Singh Dagur
2023-03-18 17:55 ` Abhishek Singh Dagur
1 sibling, 0 replies; 7+ messages in thread
From: Abhishek Singh Dagur @ 2023-03-17 17:40 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Alex Bennée, openbmc, qemu-devel, Mark Cave-Ayland,
Peter Maydell
[-- Attachment #1: Type: text/plain, Size: 5852 bytes --]
Thanks, I'll check it out.
On Fri, Mar 17, 2023 at 10:54 PM Cédric Le Goater <clg@kaod.org> wrote:
> On 3/17/23 17:06, Alex Bennée wrote:
> >
> > Abhishek Singh Dagur <abhishek@drut.io> writes:
> >
> > (cc aspeed maintainers)
> >
> >> Hi all,
> >>
> >> We are using obmc-phosphor-image on an ast2500 board which is trying to
> communicate with other devices
> >> over serial port /dev/ttyS2.
> >> As we are trying to emulate the machine on qemu we need to redirect the
> request to the host machine so
> >> that it can handle this request and return appropriately.
> >> We tried using QEMU options like -serial ,-chardev but still not the
> >> concrete way we get to do it.
> >
> > Yeah I'm afraid its non-obvious, certainly for built in serial ports.
> > Try something like:
> >
> > ./qemu-system-aarch64 -M ast2500-evb \
> > -serial null -serial null -serial chardev:myserial \
> > -chardev file,id=myserial,path=output.txt \
> > $MORE_OPTIONS
> >
> > You have to add a -serial for each serial port up to the one you care
> > about and then set the chardev for it.
> >
> > If you where adding a device to the system then you can explicitly set
> > the target chardev for it with something like:
> >
> > -device isa-serial,iobase=nnn,irq=nnn,chardev=ID
> >
> >> It will be very helpful if you can provide us some guidance on this.
> >
> > Another quirk for the aspeed boards seems to be the default uart can be
> > an arbitrary one depending on the board model:
> >
> > 334: aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
> > 336: if (uart == amc->uart_default) {
> > 1112: amc->uart_default = ASPEED_DEV_UART5;
> > 1407: amc->uart_default = ASPEED_DEV_UART1;
> >
> > as a result ASPEED_DEV_UART5 will always be the first serial port
> > (serial_hd(0)). I don't know how Linux numbers them but worth being
> > aware of.
>
> Yes. UART5 is the general default but it depends on the board definition
> and the fuji was the first to require an exception. See commit 5d63d0c76c
> ("hw/arm/aspeed: Allow machine to set UART default")
>
> Then, it became more complex with commit d2b3eaefb4 ("aspeed: Refactor
> UART init for multi-SoC machines"). That's another topic.
>
> Abhishek,
>
> I am afraid, you will need to add a new board to fit what's in the DT.
>
> Or, here is a little patch adding a machine option to set the default uart.
> It was never merged because it is a bit of hack, give it a try and we
> will discuss. Use :
>
> -M ast2500-evb,uart-default=uart2
>
>
> Thanks,
>
> C.
>
> From 0d0700ae772fa5236914e96af1be5afcf0d4a994 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
> Date: Fri, 17 Mar 2023 18:21:54 +0100
> Subject: [PATCH] aspeed: Add a "uart-default" machine option
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> hw/arm/aspeed.c | 31 +++++++++++++++++++++++++++++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 806bb10707..e0335cf167 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -45,6 +45,7 @@ struct AspeedMachineState {
> bool mmio_exec;
> char *fmc_model;
> char *spi_model;
> + uint32_t uart_default;
> uint32_t hw_strap1;
> };
>
> @@ -337,10 +338,11 @@ static void
> connect_serial_hds_to_uarts(AspeedMachineState *bmc)
> AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(bmc);
> AspeedSoCState *s = &bmc->soc;
> AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
> + int uart_default = bmc->uart_default ? bmc->uart_default :
> amc->uart_default;
>
> - aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
> + aspeed_soc_uart_set_chr(s, uart_default, serial_hd(0));
> for (int i = 1, uart = ASPEED_DEV_UART1; i < sc->uarts_num; i++,
> uart++) {
> - if (uart == amc->uart_default) {
> + if (uart == uart_default) {
> continue;
> }
> aspeed_soc_uart_set_chr(s, uart, serial_hd(i));
> @@ -1145,6 +1147,25 @@ static void aspeed_set_spi_model(Object *obj, const
> char *value, Error **errp)
> bmc->spi_model = g_strdup(value);
> }
>
> +const QEnumLookup UartDefault_lookup = {
> + .array =
> + (const char *const[]) {
> + [0] = "none",
> + [1] = "uart1",
> + [2] = "uart2",
> + [3] = "uart3",
> + [4] = "uart4",
> + [5] = "uart5",
> + },
> + .size = 6
> +};
> +
> +static void aspeed_set_uart_default(Object *obj, int val, Error **err)
> +{
> + AspeedMachineState *bmc = ASPEED_MACHINE(obj);
> + bmc->uart_default = val + 1;
> +}
> +
> static void aspeed_machine_class_props_init(ObjectClass *oc)
> {
> object_class_property_add_bool(oc, "execute-in-place",
> @@ -1153,6 +1174,12 @@ static void
> aspeed_machine_class_props_init(ObjectClass *oc)
> object_class_property_set_description(oc, "execute-in-place",
> "boot directly from CE0 flash device");
>
> + object_class_property_add_enum(oc, "uart-default", "UartDefault",
> + &UartDefault_lookup, NULL,
> + aspeed_set_uart_default);
> + object_class_property_set_description(oc, "uart-default",
> + "Change the default UART of the board");
> +
> object_class_property_add_str(oc, "fmc-model", aspeed_get_fmc_model,
> aspeed_set_fmc_model);
> object_class_property_set_description(oc, "fmc-model",
> --
> 2.39.2
>
>
>
[-- Attachment #2: Type: text/html, Size: 7253 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-17 17:24 ` Cédric Le Goater
2023-03-17 17:40 ` Abhishek Singh Dagur
@ 2023-03-18 17:55 ` Abhishek Singh Dagur
2023-03-19 17:57 ` Cédric Le Goater
1 sibling, 1 reply; 7+ messages in thread
From: Abhishek Singh Dagur @ 2023-03-18 17:55 UTC (permalink / raw)
To: Cédric Le Goater, Alex Bennée, Srinivas Kodali,
qemu-devel, Anand Moon
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
Hi Alex , Cédric,
we have tried this *option:-serial *pty* -serial *pty* -serial *pty
*-serial *pty *-serial *pty to check the serial output on screen.
Here we are providing 2 scenarios without and with the changes
suggested by @Cédric
Le Goater <clg@kaod.org> .
In first we are able to get /dev/ttyS4 serial port not /dev/ttyS2
In second we are able to get /dev/ttyS2 not /dev/ttyS4
*Scenario1:* *previously with normal qemu build i have tried emulation as:*
qemu-system-arm -m 512 -M ast2500-evb,fmc-model=mx66u51235f,spi-model=mx66u
51235f -nographic -drive file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd
-serial pty -serial pty -serial pty -serial pty
which gives us output as.
QEMU 7.2.0 monitor - type 'help' for more information
(qemu) char device redirected to /dev/pts/15 (label serial0)
char device redirected to /dev/pts/16 (label serial1)
char device redirected to /dev/pts/17 (label serial2)
char device redirected to /dev/pts/18 (label serial3)
so we can use *screen *to interact with the ttyS4 serial port like :
screen /dev/pts/15
In which we have our boot process and shell prompt .
*Scenario2:* *when I am using the newly build image with the changes *@Cédric
Le Goater <clg@kaod.org>* provided*
With the below command:
./qemu-system-arm -m 512 -M ast2500-evb,uart-default=uart2,fmc-model=mx66u
51235f,spi-model=mx66u51235f -nographic -drive
file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd
-serial pty -serial pty -serial pty -serial pty
got the output:
QEMU 7.2.90 monitor - type 'help' for more information
(qemu) char device redirected to /dev/pts/4 (label serial0)
char device redirected to /dev/pts/5 (label serial1)
char device redirected to /dev/pts/6 (label serial2)
char device redirected to /dev/pts/7 (label serial3)
where we are able to get the output of /dev/ttyS2 serial in the *screen*
/dev/pts/7
but we are not getting the output of serial /dev/ttyS4
we have tried increasing the number of *-serial pty* options also
and checked the output of each with a screen but no success.
Can you please guide us further.
Regards,
Abhishek
>
[-- Attachment #2: Type: text/html, Size: 8444 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-18 17:55 ` Abhishek Singh Dagur
@ 2023-03-19 17:57 ` Cédric Le Goater
2023-03-20 18:14 ` Abhishek Singh Dagur
0 siblings, 1 reply; 7+ messages in thread
From: Cédric Le Goater @ 2023-03-19 17:57 UTC (permalink / raw)
To: Abhishek Singh Dagur, Alex Bennée, Srinivas Kodali,
qemu-devel, Anand Moon
Hello Abhishek,
On 3/18/23 18:55, Abhishek Singh Dagur wrote:
> Hi Alex , Cédric,
> we have tried this *option:-serial *pty* -serial *pty* -serial *pty *-serial *pty *-serial *pty to check the serial output on screen.
>
> Here we are providing 2 scenarios without and with the changes suggested by @Cédric Le Goater <mailto:clg@kaod.org> .
> In first we are able to get /dev/ttyS4 serial port not /dev/ttyS2
> In second we are able to get /dev/ttyS2 not /dev/ttyS4
>
> *Scenario1:****previously with normal qemu build i have tried emulation as:*
>
> qemu-system-arm -m 512 -M ast2500-evb,fmc-model=mx66u51235f,spi-model=mx66u51235f -nographic -drive file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd -serial pty -serial pty -serial pty -serial pty
>
> which gives us output as.
>
> QEMU 7.2.0 monitor - type 'help' for more information
> (qemu) char device redirected to /dev/pts/15 (label serial0)
> char device redirected to /dev/pts/16 (label serial1)
> char device redirected to /dev/pts/17 (label serial2)
> char device redirected to /dev/pts/18 (label serial3)
>
> so we can use *screen *to interact with the ttyS4 serial port like :
> screen /dev/pts/15
> In which we have our boot process and shell prompt .
>
> *Scenario2:* *when I am using the newly build image with the changes *@Cédric Le Goater <mailto:clg@kaod.org>* provided*
>
> With the below command:
> ./qemu-system-arm -m 512 -M ast2500-evb,uart-default=uart2,fmc-model=mx66u51235f,spi-model=mx66u51235f -nographic -drive file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd -serial pty -serial pty -serial pty -serial pty
Since the machine expect /dev/ttyS2 to be the boot console, the SoC device
to attach to the first serial is UART3. This command line should output
the console logs in the same terminal :
./qemu-system-arm -m 512 -M ast2500-evb,uart-default=uart3,fmc-model=mx66u51235f,spi-model=mx66u51235f -net user -nographic -drive file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd -serial mon:stdio
I have updated the patch in my aspeed-8.0 tree :
https://github.com/legoater/qemu/commit/20fe705361dd7ed1d9129747a8a0b643410869e3
Please note that in this last version, the machine option is simply "uart".
Thanks,
C.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine.
2023-03-19 17:57 ` Cédric Le Goater
@ 2023-03-20 18:14 ` Abhishek Singh Dagur
0 siblings, 0 replies; 7+ messages in thread
From: Abhishek Singh Dagur @ 2023-03-20 18:14 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Alex Bennée, Srinivas Kodali, qemu-devel, Anand Moon
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
Thanks a lot. It's working fine 😁 now.
Abhishek.
On Sun, 19 Mar, 2023, 11:27 pm Cédric Le Goater, <clg@kaod.org> wrote:
> Hello Abhishek,
>
> On 3/18/23 18:55, Abhishek Singh Dagur wrote:
> > Hi Alex , Cédric,
> > we have tried this *option:-serial *pty* -serial *pty* -serial *pty
> *-serial *pty *-serial *pty to check the serial output on screen.
> >
> > Here we are providing 2 scenarios without and with the changes suggested
> by @Cédric Le Goater <mailto:clg@kaod.org> .
> > In first we are able to get /dev/ttyS4 serial port not /dev/ttyS2
> > In second we are able to get /dev/ttyS2 not /dev/ttyS4
> >
> > *Scenario1:****previously with normal qemu build i have tried emulation
> as:*
> >
> > qemu-system-arm -m 512 -M
> ast2500-evb,fmc-model=mx66u51235f,spi-model=mx66u51235f -nographic -drive
> file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd -serial pty -serial
> pty -serial pty -serial pty
> >
> > which gives us output as.
> >
> > QEMU 7.2.0 monitor - type 'help' for more information
> > (qemu) char device redirected to /dev/pts/15 (label serial0)
> > char device redirected to /dev/pts/16 (label serial1)
> > char device redirected to /dev/pts/17 (label serial2)
> > char device redirected to /dev/pts/18 (label serial3)
> >
> > so we can use *screen *to interact with the ttyS4 serial port like :
> > screen /dev/pts/15
> > In which we have our boot process and shell prompt .
> >
> > *Scenario2:* *when I am using the newly build image with the changes
> *@Cédric Le Goater <mailto:clg@kaod.org>* provided*
> >
> > With the below command:
> > ./qemu-system-arm -m 512 -M
> ast2500-evb,uart-default=uart2,fmc-model=mx66u51235f,spi-model=mx66u51235f
> -nographic -drive file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd
> -serial pty -serial pty -serial pty -serial pty
>
> Since the machine expect /dev/ttyS2 to be the boot console, the SoC device
> to attach to the first serial is UART3. This command line should output
> the console logs in the same terminal :
>
> ./qemu-system-arm -m 512 -M
> ast2500-evb,uart-default=uart3,fmc-model=mx66u51235f,spi-model=mx66u51235f
> -net user -nographic -drive
> file=./pru-1.2.4_dev-rc1.static.mtd,format=raw,if=mtd -serial mon:stdio
>
> I have updated the patch in my aspeed-8.0 tree :
>
>
> https://github.com/legoater/qemu/commit/20fe705361dd7ed1d9129747a8a0b643410869e3
>
> Please note that in this last version, the machine option is simply "uart".
>
> Thanks,
>
> C.
>
[-- Attachment #2: Type: text/html, Size: 3287 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-03-20 18:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-17 13:13 Using QEMU how to redirect serial /dev/ttyS2 output of guest machine to host machine Abhishek Singh Dagur
2023-03-17 16:06 ` Alex Bennée
2023-03-17 17:24 ` Cédric Le Goater
2023-03-17 17:40 ` Abhishek Singh Dagur
2023-03-18 17:55 ` Abhishek Singh Dagur
2023-03-19 17:57 ` Cédric Le Goater
2023-03-20 18:14 ` Abhishek Singh Dagur
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).