From: LIU Zhiwei <liuzwnan@163.com>
To: Alistair Francis <alistair23@gmail.com>,
LIU Zhiwei <zhiwei_liu@c-sky.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bmeng.cn@gmail.com>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
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: Thu, 4 Jun 2020 13:05:54 +0800 [thread overview]
Message-ID: <a56ffc6e-037b-5120-f22c-f18d98e8a382@163.com> (raw)
In-Reply-To: <CAKmqyKN3QBadrqzohWe0uwiCPcjU9WFHF_4j0dsKehszsZ4AWg@mail.gmail.com>
On 2020/6/4 12:35, Alistair Francis wrote:
> 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.
I tried with the UART in the virt board. It also registers the watch
callback on
G_IO_HUP and G_IO_OUT.
However I will through the question alone in another mail.
After the two points addressed,
Reviewed-by: LIU Zhiwei<zhiwei_liu@c-sky.com>
Zhiwei
>
> Alistair
>
>> Zhiwei
>>> Alistair
next prev parent reply other threads:[~2020-06-04 5:07 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
2020-06-04 5:05 ` LIU Zhiwei [this message]
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=a56ffc6e-037b-5120-f22c-f18d98e8a382@163.com \
--to=liuzwnan@163.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.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).