From: Alistair Francis <alistair23@gmail.com>
To: LIU Zhiwei <zhiwei_liu@c-sky.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
Bin Meng <bmeng.cn@gmail.com>,
Alistair Francis <alistair.francis@wdc.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v5 07/11] hw/char: Initial commit of Ibex UART
Date: Wed, 3 Jun 2020 21:35:50 -0700 [thread overview]
Message-ID: <CAKmqyKN3QBadrqzohWe0uwiCPcjU9WFHF_4j0dsKehszsZ4AWg@mail.gmail.com> (raw)
In-Reply-To: <aa240d2d-42bb-b9dd-90f0-1a3051c2491f@c-sky.com>
On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
>
>
>
> On 2020/6/3 23:56, Alistair Francis wrote:
> > On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
> >> On 2020/6/3 1:54, Alistair Francis wrote:
> >>> On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei<zhiwei_liu@c-sky.com> wrote:
> >>>> Hi Alistair,
> >>>>
> >>>> There are still some questions I don't understand.
> >>>>
> >>>> 1. Is the baud rate or fifo a necessary feature to simulate?
> >>>> As you can see, qemu_chr_fe_write will send the byte as soon as possible.
> >>>> When you want to transmit a byte through WDATA, you can call
> >>>> qemu_chr_fe_write directly.
> >>> So qemu_chr_fe_write() will send the data straight away. This doesn't
> >>> match what teh hardware does though. So by modelling a FIFO and a
> >>> delay in sending we can better match the hardware.
> >> I see many UARTs have similar features. Does the software really care about
> >> these features? Usually I just want to print something to the terminal
> >> through UART.
> > In this case Tock (which is the OS used for OpenTitan) does car about
> > these features as it relies on interrupts generated by the HW to
> > complete the serial send task. It also just makes the QEMU model more
> > accurate.
>
> Fair enough. I see the "tx_watermark" interrupt, which needs the FIFO.
> At least,
> it can verify the ISP.
Exactly :)
> >> Most simulation in QEMU is for running software, not exactly the details
> >> of hardware.
> >> For example, we will not simulate the 16x oversamples in this UART.
> > Agreed. Lots of UARTs don't bother modelling the delay from the
> > hardware as generally it doesn't matter. In this case it does make a
> > difference for the software and it makes the QEMU model more accurate,
> > which is always a good thing.
> >
> >> There is no error here. Personally I think it is necessary to simulate
> >> the FIFO and baud rate,
> >> maybe for supporting some backends.
> > So baud rate doesn't need to be modelled as we aren't actually sending
> > UART data, just pretending and then printing it.
> >
> >> Can someone give a reasonable answer for this question?
> > Which question?
> I see the UART can work with many different backends, such as pty ,
> file, socket and so on.
> I wonder if this a backend, which has some requirements on the baud
The backend should be independent so it doesn't matter what baud rate
we choose here.
> rate. You can ignore it,
> as it doesn't matter.
> >
> >>>> 2. The baud rate calculation method is not strictly right.
> >>>> I think when a byte write to FIFO, char_tx_time * 8 is the correct time
> >>>> to send the byte instead of
> >>>> char_tx_time * 4.
> >>> Do you mind explaining why 8 is correct instead of 4?
> >> Usually write a byte to WDATA will trigger a uart_write_tx_fifo.
> >> Translate a bit will take
> >> char_tx_time. So it will take char_tx_time * 8 to transmit a byte.
> > I see your point. I just used the 4 as that is what the Cadence one
> > does. I don't think it matters too much as it's just the delay for a
> > timer (that isn't used as an accurate timer).
> Got it. Just a way to send the bytes at sometime later.
> >>>> 3. Why add a watch here?
> >>> This is based on the Cadence UART implementation in QEMU (which does
> >>> the same thing). This will trigger a callback when we can write more
> >>> data or when the backend has hung up.
> >> Many other serials do the same thing, like virtio-console and serial. So
> >> it may be a common
> >> interface here. I will try to understand it(Not yet).
> > Yep, it's just a more complete model of that the HW does.
> I try to boot a RISC-V Linux, and set a breakpoint to a watch callback
> function.
> The breakpoint did't match.
>
> I just wonder if there is a case really need the callback function.
AFAIK Linux doesn't support the Ibex UART (or Ibex at all) so it
shouldn't be triggered.
Alistair
>
> Zhiwei
> >
> > Alistair
>
next prev parent reply other threads:[~2020-06-04 4:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 22:14 [PATCH v5 00/11] RISC-V Add the OpenTitan Machine Alistair Francis
2020-05-28 22:14 ` [PATCH v5 01/11] riscv/boot: Add a missing header include Alistair Francis
2020-05-28 22:14 ` [PATCH v5 02/11] target/riscv: Don't overwrite the reset vector Alistair Francis
2020-05-28 22:14 ` [PATCH v5 03/11] target/riscv: Disable the MMU correctly Alistair Francis
2020-06-01 5:24 ` Bin Meng
2020-05-28 22:14 ` [PATCH v5 04/11] target/riscv: Don't set PMP feature in the cpu init Alistair Francis
2020-06-01 5:26 ` Bin Meng
2020-05-28 22:14 ` [PATCH v5 05/11] target/riscv: Add the lowRISC Ibex CPU Alistair Francis
2020-05-28 22:14 ` [PATCH v5 06/11] riscv: Initial commit of OpenTitan machine Alistair Francis
2020-06-09 13:48 ` Damien Hedde
2020-06-09 14:21 ` Philippe Mathieu-Daudé
2020-06-09 23:09 ` Alistair Francis
2020-09-08 14:52 ` Peter Maydell
2020-09-09 17:49 ` Alistair Francis
2020-09-09 19:00 ` Peter Maydell
2020-09-09 19:51 ` Palmer Dabbelt
2020-09-10 18:48 ` Alistair Francis
2023-05-19 17:15 ` [PATCH v5 6/11] " Philippe Mathieu-Daudé
2020-05-28 22:14 ` [PATCH v5 07/11] hw/char: Initial commit of Ibex UART Alistair Francis
2020-06-01 21:23 ` Alistair Francis
2020-06-02 11:22 ` LIU Zhiwei
2020-06-02 12:28 ` LIU Zhiwei
2020-06-02 17:54 ` Alistair Francis
2020-06-03 10:33 ` LIU Zhiwei
2020-06-03 15:56 ` Alistair Francis
2020-06-04 1:59 ` LIU Zhiwei
2020-06-04 4:35 ` Alistair Francis [this message]
2020-06-04 5:05 ` LIU Zhiwei
2020-06-04 5:46 ` Alistair Francis
2020-06-04 5:40 ` LIU Zhiwei
2020-06-02 17:46 ` Alistair Francis
2020-05-28 22:14 ` [PATCH v5 08/11] hw/intc: Initial commit of lowRISC Ibex PLIC Alistair Francis
2020-05-28 22:14 ` [PATCH v5 09/11] riscv/opentitan: Connect the PLIC device Alistair Francis
2020-05-28 22:14 ` [PATCH v5 10/11] riscv/opentitan: Connect the UART device Alistair Francis
2020-05-28 22:14 ` [PATCH v5 11/11] target/riscv: Use a smaller guess size for no-MMU PMP Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKN3QBadrqzohWe0uwiCPcjU9WFHF_4j0dsKehszsZ4AWg@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=alistair.francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@c-sky.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).