From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD8C5C433DF for ; Thu, 4 Jun 2020 05:41:30 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4B012206DC for ; Thu, 4 Jun 2020 05:41:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B012206DC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-sky.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgid7-0000Vq-G8 for qemu-devel@archiver.kernel.org; Thu, 04 Jun 2020 01:41:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34716) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgicB-0008Sy-IP; Thu, 04 Jun 2020 01:40:31 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:51305) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgic7-0004qn-Kl; Thu, 04 Jun 2020 01:40:30 -0400 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.04436291|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.04455-6.83485e-05-0.955382; FP=8933452467350914499|1|1|3|0|-1|-1|-1; HT=e02c03267; MF=zhiwei_liu@c-sky.com; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HhwcvST_1591249214; Received: from 30.225.208.46(mailfrom:zhiwei_liu@c-sky.com fp:SMTPD_---.HhwcvST_1591249214) by smtp.aliyun-inc.com(10.147.41.187); Thu, 04 Jun 2020 13:40:15 +0800 Subject: Re: [PATCH v5 07/11] hw/char: Initial commit of Ibex UART To: Alistair Francis References: <73cce2d0edd0d41ba15df403a2096bfa70bf0565.1590704015.git.alistair.francis@wdc.com> From: LIU Zhiwei Message-ID: Date: Thu, 4 Jun 2020 13:40:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: none client-ip=121.197.200.217; envelope-from=zhiwei_liu@c-sky.com; helo=smtp2200-217.mail.aliyun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 01:40:16 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:RISC-V" , Bin Meng , Alistair Francis , Palmer Dabbelt , "qemu-devel@nongnu.org Developers" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2020/6/4 12:35, Alistair Francis wrote: > On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote: >> >> >> On 2020/6/3 23:56, Alistair Francis wrote: >>> On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote: >>>> On 2020/6/3 1:54, Alistair Francis wrote: >>>>> On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei 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 throw the question alone in another thread. After the two comments pointed at another email addressed, Reviewed-by: LIU Zhiwei Zhiwei > > Alistair > >> Zhiwei >>> Alistair From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jgicE-0008Te-R9 for mharc-qemu-riscv@gnu.org; Thu, 04 Jun 2020 01:40:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34716) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgicB-0008Sy-IP; Thu, 04 Jun 2020 01:40:31 -0400 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:51305) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgic7-0004qn-Kl; Thu, 04 Jun 2020 01:40:30 -0400 X-Alimail-AntiSpam: AC=CONTINUE; BC=0.04436291|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.04455-6.83485e-05-0.955382; FP=8933452467350914499|1|1|3|0|-1|-1|-1; HT=e02c03267; MF=zhiwei_liu@c-sky.com; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HhwcvST_1591249214; Received: from 30.225.208.46(mailfrom:zhiwei_liu@c-sky.com fp:SMTPD_---.HhwcvST_1591249214) by smtp.aliyun-inc.com(10.147.41.187); Thu, 04 Jun 2020 13:40:15 +0800 Subject: Re: [PATCH v5 07/11] hw/char: Initial commit of Ibex UART To: Alistair Francis Cc: Alistair Francis , "open list:RISC-V" , Bin Meng , Palmer Dabbelt , "qemu-devel@nongnu.org Developers" References: <73cce2d0edd0d41ba15df403a2096bfa70bf0565.1590704015.git.alistair.francis@wdc.com> From: LIU Zhiwei Message-ID: Date: Thu, 4 Jun 2020 13:40:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: none client-ip=121.197.200.217; envelope-from=zhiwei_liu@c-sky.com; helo=smtp2200-217.mail.aliyun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 01:40:16 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-riscv@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 05:40:32 -0000 On 2020/6/4 12:35, Alistair Francis wrote: > On Wed, Jun 3, 2020 at 6:59 PM LIU Zhiwei wrote: >> >> >> On 2020/6/3 23:56, Alistair Francis wrote: >>> On Wed, Jun 3, 2020 at 3:33 AM LIU Zhiwei wrote: >>>> On 2020/6/3 1:54, Alistair Francis wrote: >>>>> On Tue, Jun 2, 2020 at 5:28 AM LIU Zhiwei 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 throw the question alone in another thread. After the two comments pointed at another email addressed, Reviewed-by: LIU Zhiwei Zhiwei > > Alistair > >> Zhiwei >>> Alistair