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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 24A99C4338F for ; Mon, 26 Jul 2021 07:09:05 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E77A260F42 for ; Mon, 26 Jul 2021 07:09:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E77A260F42 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C453D832B0; Mon, 26 Jul 2021 09:08:59 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id A0B5D832B1; Mon, 26 Jul 2021 09:08:57 +0200 (CEST) Received: from ATCSQR.andestech.com (atcsqr.andestech.com [60.248.187.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EEF76832AB for ; Mon, 26 Jul 2021 09:08:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ycliang@andestech.com Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id 16Q78EZR078553; Mon, 26 Jul 2021 15:08:14 +0800 (GMT-8) (envelope-from ycliang@andestech.com) Received: from andestech.com (10.0.15.65) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.498.0; Mon, 26 Jul 2021 15:08:15 +0800 Date: Mon, 26 Jul 2021 15:08:16 +0800 From: Leo Liang To: Sean Anderson CC: Heinrich Schuchardt , Rick Jian-Zhi =?utf-8?B?Q2hlbijpmbPlu7rlv5cp?= , Bin Meng , Atish Patra , Pragnesh Patel , "u-boot@lists.denx.de" , Dimitri John Ledkov , Heinrich Schuchardt Subject: Re: [PATCH 2/2] cmd/sbi: add missing SBI information Message-ID: <20210726070806.GB983@andestech.com> References: <20210719202835.23081-1-xypron.glpk@gmx.de> <20210719202835.23081-3-xypron.glpk@gmx.de> <3e6601f5-8fbf-44dd-cacb-7a713d24faf2@gmail.com> <4AA9BE7D-FF84-482E-A061-2284CE71EB50@gmx.de> <30512559-ac9a-8d4a-2857-16d8957c9029@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <30512559-ac9a-8d4a-2857-16d8957c9029@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.15.65] X-DNSRBL: X-MAIL: ATCSQR.andestech.com 16Q78EZR078553 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Tue, Jul 20, 2021 at 01:13:56PM +0800, Sean Anderson wrote: > On 7/20/21 12:59 AM, Heinrich Schuchardt wrote: > > Am 20. Juli 2021 03:11:34 MESZ schrieb Sean Anderson : > >> On 7/19/21 4:28 PM, Heinrich Schuchardt wrote: > >>> Let the sbi command display: > >>> > >>> * SBI implementation version > >>> * machine vendor ID > >>> * machine architecture ID > >>> * machine implementation ID > >>> > >>> With this patch the output for the HiFive Unmatched looks like > >>> > >>> => sbi > >>> SBI 0.3 > >>> OpenSBI 0.9 > >>> Machine: > >>> Vendor ID 489 > >>> Architecture ID 8000000000000007 > >>> Implementation ID 20181004 > >>> Extensions: > >>> sbi_set_timer > >>> sbi_console_putchar > >>> sbi_console_getchar > >>> sbi_clear_ipi > >>> sbi_send_ipi > >>> sbi_remote_fence_i > >>> sbi_remote_sfence_vma > >>> sbi_remote_sfence_vma_asid > >>> sbi_shutdown > >>> SBI Base Functionality > >>> Timer Extension > >>> IPI Extension > >>> RFENCE Extension > >>> Hart State Management Extension > >>> System Reset Extension > >>> > >>> Signed-off-by: Heinrich Schuchardt > >> > >>> --- > >>> cmd/riscv/sbi.c | 19 ++++++++++++++++++- > >>> 1 file changed, 18 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/cmd/riscv/sbi.c b/cmd/riscv/sbi.c > >>> index 90c0811e14..c0db763ba7 100644 > >>> --- a/cmd/riscv/sbi.c > >>> +++ b/cmd/riscv/sbi.c > >>> @@ -59,13 +59,30 @@ static int do_sbi(struct cmd_tbl *cmdtp, int > >> flag, int argc, > >>> if (ret >= 0) { > >>> for (i = 0; i < ARRAY_SIZE(implementations); ++i) { > >>> if (ret == implementations[i].id) { > >>> - printf("%s\n", implementations[i].name); > >>> + printf("%s", implementations[i].name); > >>> + ret = sbi_get_impl_version(); > >>> + if (ret > 0) { > >> > >> Shouldn't this have to check to ensure that i == 1? > > > > Other SBI implementions may also provide a version number. I did not analyze how the should be formatted. > > Right, so shouldn't we default to the raw hex string? +1 > > > > >> > >>> + /* OpenSBI specific version encoding */ > >>> + printf(" %ld", ret >> 16); > >>> + printf(".%ld", ret & 0xffff); > >>> + } > >>> + printf("\n"); > >>> break; > >>> } > >>> } > >>> if (i == ARRAY_SIZE(implementations)) > >>> printf("Unknown implementation ID %ld\n", ret); > >>> } > >>> + printf("Machine:\n"); > >>> + ret = sbi_get_mvendorid(); > >>> + if (ret != -ENOTSUPP) > > > > Should we use an unsigned int as return value and 0 to indicate a missing implementation? mvendorid is only 32 bits wide. > > > >>> + printf(" Vendor ID %lx\n", ret); > >> > >> perhaps %0.8lx? And should we decode the JEDEC id? > > > > Leading zeros won't add any meaning here. Splitting into the 25 bit and 7 bit subfields could be reasonable. > > I think this would be a good option. +1 with 25, 7 split. IMHO, perhaps we could show only the "numbers" of the continuation code and the "decoded offset" ? Something like: vendor ID: 489, continuation code: 9, offset decoded: 0x89. Best regards, Leo > > > Decoding could result in up to 2^26 digits. I don't want to wait for all of these on my serial console. > > Well, they're only up to 12 continuation codes, so imposing a small maximum would likely not be too onerous. > > --Sean