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=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 17106C47080 for ; Tue, 1 Jun 2021 18:38:26 +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 34C016023B for ; Tue, 1 Jun 2021 18:38:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34C016023B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo9HU-0001a0-Bg for qemu-devel@archiver.kernel.org; Tue, 01 Jun 2021 14:38:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo9Gj-0000op-Gx for qemu-devel@nongnu.org; Tue, 01 Jun 2021 14:37:37 -0400 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:45786) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lo9Gg-0006Zu-PD for qemu-devel@nongnu.org; Tue, 01 Jun 2021 14:37:37 -0400 Received: by mail-ej1-x636.google.com with SMTP id k7so13698715ejv.12 for ; Tue, 01 Jun 2021 11:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8lyh9LUX7vehsIV1GTvaa4aECYiZaAvk0/weS/g7IU=; b=WjQ8is1otZ5e7y4gucHbp9uiSntzcZEj6PfFPHX/b6GWN+2W9C1IH5ELj7IjliiGBY e/8a3QDD5j4n+iWSn5foKdeb8Y+rYhg3v/5ButM1+AFTbtfB8BfEsRoX3CZgO9Z27ykX 3wgrDYT9BpAQfjy2tdd3/8EkejxW3elnUPqafE9ke21aylVTehpQ+Yp92tzMFMTYQ4wa Pp6wYeLom8nHlXAY6MhCYDICAqj3MFr1tHQSnYrWlQ7Rei+zUnmPw+aqFY9qC27fw/8J GDmbIClHyY9Gc1v3o966Xl5I8TuV3Ad29HTIyH7V0osGodHIZpAVx74daxI7sHBK6zvw PFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8lyh9LUX7vehsIV1GTvaa4aECYiZaAvk0/weS/g7IU=; b=UXgaIBNmuaagkcY4QtmnNYRf7UBQhjulW+I9DudVzDSAm7PjUyXEmKLXZyn+0cr9pN pCrWMO8E6jLp3AAhgMqj7c3ijSNFP1D8/1Wl0bVcKudhNzlwCoG+nxW70jXwsNdUpjFk 9Hr5yMBOx1SbOvRRYrxvrxX6RHwYxQ9p2NGdw9S/rQ67Jyh3QoghBHsw3+ye++3vAQgk cHfn0DOqadun5+KKIBLab0mCU/9iT/2a5j3T7kkpBRPpusAB9NqpslTb5o0tNuEJXa2V WU+r3TyfBLmly7NRRgE28XHozYPG3arv8bBjqneyMwISlHyCOzHtu6KL8U90yT5N2EY5 ///g== X-Gm-Message-State: AOAM530JNSSWt0ldbppqCMQDeoV8tsF8zZ45TQxWXhh0qszt1fSCKLB5 JtCsIj9mukn3S90Mjowj1EKJ5tn92jeS34ffcX2rog== X-Google-Smtp-Source: ABdhPJzL3CtpzTNjtdrKOAw9iq1OGsosf71eYBHicC+q/xuLOJl6Z4mb411B8aZFMZEZfXXirY4zdVpv8S9aQlvsozk= X-Received: by 2002:a17:906:c1ca:: with SMTP id bw10mr31196958ejb.512.1622572653018; Tue, 01 Jun 2021 11:37:33 -0700 (PDT) MIME-Version: 1.0 References: <0CAA9018-0C42-4140-82C1-EAC80D46D359@getmailspring.com> In-Reply-To: From: Rahul Pathak Date: Wed, 2 Jun 2021 00:06:56 +0530 Message-ID: Subject: Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit To: Bin Meng Content-Type: multipart/alternative; boundary="0000000000009b1c0605c3b8a20b" Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=rpathak@ventanamicro.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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: Alistair Francis , Rahul Pathak , "open list:RISC-V" , "qemu-devel@nongnu.org Developers" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000009b1c0605c3b8a20b Content-Type: text/plain; charset="UTF-8" I swapped the serial_hd() index between the MMUART0 and MMUART1 , so my default qemu console is the MMUART1. I can see the U-Boot and Kernel logs now. I still need both serial consoles for HSS and UBoot/Kernel and will need your help to make the original qemu command line work with unix\#serial1.sock. I am unable to figure out what's wrong with unix\#serial1.sock On Tue, Jun 1, 2021 at 7:48 PM Rahul Pathak wrote: > Hi Bin, > > Thanks for the response. > > I think the issue currently is that if I keep the "wait=on" and launch > minicom on "unix\#serial1.sock" then nothing happens. > Qemu keeps waiting for the connection on serial1 and no logs for uboot and > Kernel appears on the serial1. > > Thanks > Rahul > > On Tue, Jun 1, 2021 at 7:39 PM Bin Meng wrote: > >> Hi Rahul, >> >> On Tue, Jun 1, 2021 at 11:12 AM Rahul Pathak >> wrote: >> > >> > Hi BIn,Alistair, >> > >> > I was passing the hss.elf file and it was strange that gdb after >> connecting was not letting the target to continue from gdb. >> >> This is the expected behavior if you pass an image to gdb before >> connecting to the target, as gdb will assume the debug contexts are >> the same, but it's not the case for PolarFire which has 1+4 hybrid >> configuration. >> >> > what worked was to not pass anything and then connect the to target >> then load the symbol file as hss.elf. >> > I followed the steps from the "Attaching the GDB" doc and was able to >> debug. >> > >> >> Yes, that's the correct way to debug PolarFire. >> >> > >> > For the qemu command line from the doc, I made the "wait=off" then qemu >> was not waiting for another serial connection >> > and launched the hss. >> >> You need to connect to the other serial connection otherwise QEMU does >> not start the emulation when "wait=on" >> >> > >> > >> > The problem remains is that I still do not have the u-boot and linux >> booting. The unix\#serial1.sock remains offline always. >> > These are the HSS logs - >> > >> > [0.115001] HSS_E51_Banner(): PolarFire(R) SoC Hart Software Services >> (HSS) - version 0.99.15 >> > (c) Copyright 2017-2020 Microchip Corporation. >> > >> > [0.116234] HSS_E51_Banner(): incorporating OpenSBI - version 0.6 >> > (c) Copyright 2019-2020 Western Digital Corporation. >> > >> > [0.117071] HSS_PrintBuildId(): Build ID: >> 811342a39f80176f9e2086bf963a83224b3d3a2e >> > [0.117817] HSS_PrintToolVersions(): Built with the following tools: >> > - riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0 >> >> Yeah, this log indicates that GCC 10.x works with HSS :) >> >> > - GNU ld (GNU Binutils) 2.36.1 >> > >> > [0.118760] HSS_MemTestDDRFast(): DDR size is 1 GiB >> > [0.130270] HSS_MMCInit(): Attempting to select SDCARD ... Passed >> > Press a key to enter CLI, ESC to skip >> > Timeout in 5 seconds >> > >> > ..... >> > [5.138747] HSS_TinyCLI_Parser(): CLI check timeout >> > [5.139371] IPI_QueuesInit(): Initializing IPI Queues (9000 bytes @ >> 8000e40)... >> > [5.140435] HSS_PMP_Init(): Initializing PMPs >> > [5.141093] HSS_BootInit(): Initializing Boot Image.. >> > [5.141787] getBootImageFromMMC_(): Preparing to copy from MMC to DDR ... >> > [5.142671] getBootImageFromMMC_(): Attempting to read image header >> (1552 bytes) ... >> > [5.144118] GPT_ValidateHeader(): Validated GPT Header ... >> > [5.153768] GPT_ValidatePartitionEntries(): Validated GPT Partition >> Entries ... >> > [5.155210] copyBootImageToDDR_(): Copying 436008 bytes to 0xA0000000 >> > [5.407848] copyBootImageToDDR_(): Calculated CRC32 of image in DDR is >> 795fbbea >> > [5.412058] HSS_BootInit(): boot image passed CRC >> > [5.412407] HSS_BootInit(): Boot image set name: >> "PolarFire-SoC-HSS::U-Boot" >> > [5.412951] HSS_BootInit(): Boot Image registered... >> > [5.413376] HSS_Boot_RestartCore(): called for all harts >> > [5.414295] RunStateMachine(): boot_service(u54_1)::Init -> >> boot_service(u54_1)::SetupPMP >> > [5.414812] RunStateMachine(): boot_service(u54_2)::Init -> >> boot_service(u54_2)::SetupPMP >> > [5.415207] RunStateMachine(): boot_service(u54_3)::Init -> >> boot_service(u54_3)::SetupPMP >> > [5.415631] RunStateMachine(): boot_service(u54_4)::Init -> >> boot_service(u54_4)::SetupPMP >> > [5.416107] RunStateMachine(): usbdmsc_service::init -> >> usbdmsc_service::idle >> > [5.417164] RunStateMachine(): boot_service(u54_1)::SetupPMP -> >> boot_service(u54_1)::SetupPMPComplete >> > [5.417887] RunStateMachine(): boot_service(u54_2)::SetupPMP -> >> boot_service(u54_2)::SetupPMPComplete >> > [5.418552] RunStateMachine(): boot_service(u54_3)::SetupPMP -> >> boot_service(u54_3)::SetupPMPComplete >> > [5.419890] RunStateMachine(): boot_service(u54_4)::SetupPMP -> >> boot_service(u54_4)::SetupPMPComplete >> > [23.955147] RunStateMachine(): boot_service(u54_1)::SetupPMPComplete -> >> boot_service(u54_1)::ZeroInit >> > [23.955754] RunStateMachine(): boot_service(u54_2)::SetupPMPComplete -> >> boot_service(u54_2)::ZeroInit >> > [23.956259] RunStateMachine(): boot_service(u54_3)::SetupPMPComplete -> >> boot_service(u54_3)::ZeroInit >> > [23.956757] RunStateMachine(): boot_service(u54_4)::SetupPMPComplete -> >> boot_service(u54_4)::ZeroInit >> > [23.957371] RunStateMachine(): boot_service(u54_1)::ZeroInit -> >> boot_service(u54_1)::Download >> > [23.957876] RunStateMachine(): boot_service(u54_2)::ZeroInit -> >> boot_service(u54_2)::Download >> > [23.958386] RunStateMachine(): boot_service(u54_3)::ZeroInit -> >> boot_service(u54_3)::Download >> > [23.958856] RunStateMachine(): boot_service(u54_4)::ZeroInit -> >> boot_service(u54_4)::Download >> > [23.960300] RunStateMachine(): boot_service(u54_2)::Download -> >> boot_service(u54_2)::Idle >> > [23.960723] RunStateMachine(): boot_service(u54_3)::Download -> >> boot_service(u54_3)::Idle >> > [23.961129] RunStateMachine(): boot_service(u54_4)::Download -> >> boot_service(u54_4)::Idle >> > [23.983168] RunStateMachine(): boot_service(u54_1)::Download -> >> boot_service(u54_1)::Wait >> > [23.983661] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_2:sbi_init 80200000 >> > [23.984374] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_3:sbi_init 80200000 >> > [23.985418] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_4:sbi_init 80200000 >> > [23.986783] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_1:sbi_init 80200000 >> > [23.989086] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI >> ACKs: - - >> > [23.992106] boot_wait_handler(): boot_service(u54_1)::Checking for IPI >> ACKs: ACK/IDLE ACK >> > [23.994062] RunStateMachine(): boot_service(u54_1)::Wait -> >> boot_service(u54_1)::Idle >> > >> >> Based on the above log, HSS successfully boots U-Boot already. The >> U-Boot console is on the other serial console, which I guess you might >> turn it off? >> >> > >> > One thing I overlooked in the document is that we are preparing the >> *.wic file after downloading >> > but passing the *.img in the qemu command. How to convert the wic to >> img. I couldn't see much about >> > this on the internet ? >> >> The *.wic image is the raw image. Just use it as it is. >> >> > Since U-boot currently does not boot, it seems passing the wic file >> directly is not right. Now sure here. >> > >> > qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \ >> > -bios path/to/hss.bin -sd path/to/sdcard.img \ >> > -nic user,model=cadence_gem \ >> > -nic tap,ifname=tap,model=cadence_gem,script=no \ >> > -display none -serial stdio \ >> > -chardev socket,id=serial1,path=serial1.sock,server=on,wait=on \ >> > -serial chardev:serial1 >> > >> > >> > Are there other ways in qemu icicle machine supported now to pass the >> u-boot and kernel? >> > >> >> Yes, it has. The capability to direct boot kernel (can be U-Boot or an >> OS kernel) without HSS is currently in the Alistair's riscv-next tree >> and should land on qemu/master soon. >> >> Regards, >> Bin >> > --0000000000009b1c0605c3b8a20b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I swapped the serial_hd() index between the MMUART0 and MMUART1= =C2=A0, so my default qemu console is the MMUART1.
I can see the U-Boot and= Kernel logs now.=C2=A0

I still need both serial consoles for HSS and = UBoot/Kernel and will need your help to make the original qemu command line= work with unix\#serial1.sock.
I am unable to figure out what's wrong w= ith=C2=A0unix\#serial1.sock

On Tue, Jun 1, 2021 at 7:48 PM Rahul Patha= k <rpathak= @ventanamicro.com> wrote:
Hi Bin,

Thanks for the response.=C2=A0
I think the issue currently=C2=A0is that if I keep the "wait=3Don&q= uot; and launch minicom on=C2=A0 "unix\#serial1.sock" then nothin= g happens.
Qemu keeps waiting for the connection on serial1 and no logs for= uboot and Kernel appears on the serial1.

Thanks
Rahul

=
On Tue, Ju= n 1, 2021 at 7:39 PM Bin Meng <bmeng.cn@gmail.com> wrote:
Hi Rahul,

On Tue, Jun 1, 2021 at 11:12 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:=
>
> Hi BIn,Alistair,
>
> I was passing the hss.elf file and it was strange that gdb after conne= cting was not letting the target to continue from gdb.

This is the expected behavior if you pass an image to gdb before
connecting to the target, as gdb will assume the debug contexts are
the same, but it's not the case for PolarFire which has 1+4 hybrid
configuration.

> what worked was to not pass anything and then connect the to target th= en load the symbol file as hss.elf.
> I followed the steps from the "Attaching the GDB" doc and wa= s able to debug.
>

Yes, that's the correct way to debug PolarFire.

>
> For the qemu command line from the doc, I made the "wait=3Doff&qu= ot; then qemu was not waiting for another serial connection
> and launched the hss.

You need to connect to the other serial connection otherwise QEMU does
not start the emulation when "wait=3Don"

>
>
> The problem remains is that I still do not have the u-boot and linux b= ooting. The unix\#serial1.sock remains offline always.
> These are the HSS logs -
>
> [0.115001] HSS_E51_Banner(): PolarFire(R) SoC Hart Software Services (= HSS) - version 0.99.15
> (c) Copyright 2017-2020 Microchip Corporation.
>
> [0.116234] HSS_E51_Banner(): incorporating OpenSBI - version 0.6
> (c) Copyright 2019-2020 Western Digital Corporation.
>
> [0.117071] HSS_PrintBuildId(): Build ID: 811342a39f80176f9e2086bf963a8= 3224b3d3a2e
> [0.117817] HSS_PrintToolVersions(): Built with the following tools: >=C2=A0 - riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0

Yeah, this log indicates that GCC 10.x works with HSS :)

>=C2=A0 - GNU ld (GNU Binutils) 2.36.1
>
> [0.118760] HSS_MemTestDDRFast(): DDR size is 1 GiB
> [0.130270] HSS_MMCInit(): Attempting to select SDCARD ... Passed
> Press a key to enter CLI, ESC to skip
> Timeout in 5 seconds
>
> .....
> [5.138747] HSS_TinyCLI_Parser(): CLI check timeout
> [5.139371] IPI_QueuesInit(): Initializing IPI Queues (9000 bytes @ 800= 0e40)...
> [5.140435] HSS_PMP_Init(): Initializing PMPs
> [5.141093] HSS_BootInit(): Initializing Boot Image..
> [5.141787] getBootImageFromMMC_(): Preparing to copy from MMC to DDR .= ..
> [5.142671] getBootImageFromMMC_(): Attempting to read image header (15= 52 bytes) ...
> [5.144118] GPT_ValidateHeader(): Validated GPT Header ...
> [5.153768] GPT_ValidatePartitionEntries(): Validated GPT Partition Ent= ries ...
> [5.155210] copyBootImageToDDR_(): Copying 436008 bytes to 0xA0000000 > [5.407848] copyBootImageToDDR_(): Calculated CRC32 of image in DDR is = 795fbbea
> [5.412058] HSS_BootInit():=C2=A0 boot image passed CRC
> [5.412407] HSS_BootInit(): Boot image set name: "PolarFire-SoC-HS= S::U-Boot"
> [5.412951] HSS_BootInit(): Boot Image registered...
> [5.413376] HSS_Boot_RestartCore(): called for all harts
> [5.414295] RunStateMachine(): boot_service(u54_1)::Init -> boot_ser= vice(u54_1)::SetupPMP
> [5.414812] RunStateMachine(): boot_service(u54_2)::Init -> boot_ser= vice(u54_2)::SetupPMP
> [5.415207] RunStateMachine(): boot_service(u54_3)::Init -> boot_ser= vice(u54_3)::SetupPMP
> [5.415631] RunStateMachine(): boot_service(u54_4)::Init -> boot_ser= vice(u54_4)::SetupPMP
> [5.416107] RunStateMachine(): usbdmsc_service::init -> usbdmsc_serv= ice::idle
> [5.417164] RunStateMachine(): boot_service(u54_1)::SetupPMP -> boot= _service(u54_1)::SetupPMPComplete
> [5.417887] RunStateMachine(): boot_service(u54_2)::SetupPMP -> boot= _service(u54_2)::SetupPMPComplete
> [5.418552] RunStateMachine(): boot_service(u54_3)::SetupPMP -> boot= _service(u54_3)::SetupPMPComplete
> [5.419890] RunStateMachine(): boot_service(u54_4)::SetupPMP -> boot= _service(u54_4)::SetupPMPComplete
> [23.955147] RunStateMachine(): boot_service(u54_1)::SetupPMPComplete -= > boot_service(u54_1)::ZeroInit
> [23.955754] RunStateMachine(): boot_service(u54_2)::SetupPMPComplete -= > boot_service(u54_2)::ZeroInit
> [23.956259] RunStateMachine(): boot_service(u54_3)::SetupPMPComplete -= > boot_service(u54_3)::ZeroInit
> [23.956757] RunStateMachine(): boot_service(u54_4)::SetupPMPComplete -= > boot_service(u54_4)::ZeroInit
> [23.957371] RunStateMachine(): boot_service(u54_1)::ZeroInit -> boo= t_service(u54_1)::Download
> [23.957876] RunStateMachine(): boot_service(u54_2)::ZeroInit -> boo= t_service(u54_2)::Download
> [23.958386] RunStateMachine(): boot_service(u54_3)::ZeroInit -> boo= t_service(u54_3)::Download
> [23.958856] RunStateMachine(): boot_service(u54_4)::ZeroInit -> boo= t_service(u54_4)::Download
> [23.960300] RunStateMachine(): boot_service(u54_2)::Download -> boo= t_service(u54_2)::Idle
> [23.960723] RunStateMachine(): boot_service(u54_3)::Download -> boo= t_service(u54_3)::Idle
> [23.961129] RunStateMachine(): boot_service(u54_4)::Download -> boo= t_service(u54_4)::Idle
> [23.983168] RunStateMachine(): boot_service(u54_1)::Download -> boo= t_service(u54_1)::Wait
> [23.983661] boot_download_chunks_onExit(): boot_service(u54_1)::u54_2:= sbi_init 80200000
> [23.984374] boot_download_chunks_onExit(): boot_service(u54_1)::u54_3:= sbi_init 80200000
> [23.985418] boot_download_chunks_onExit(): boot_service(u54_1)::u54_4:= sbi_init 80200000
> [23.986783] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:= sbi_init 80200000
> [23.989086] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI= ACKs: - -
> [23.992106] boot_wait_handler(): boot_service(u54_1)::Checking for IPI= ACKs: ACK/IDLE ACK
> [23.994062] RunStateMachine(): boot_service(u54_1)::Wait -> boot_se= rvice(u54_1)::Idle
>

Based on the above log, HSS successfully boots U-Boot already. The
U-Boot console is on the other serial console, which I guess you might
turn it off?

>
> One thing I overlooked in the document is that we are preparing the *.= wic file after downloading
> but passing the *.img in the qemu command. How to convert the wic to i= mg. I couldn't see much about
> this on the internet ?

The *.wic image is the raw image. Just use it as it is.

> Since U-boot currently does not boot, it seems passing the wic file di= rectly is not right. Now sure here.
>
>=C2=A0 qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
>=C2=A0 =C2=A0 =C2=A0-bios path/to/hss.bin -sd path/to/sdcard.img \
>=C2=A0 =C2=A0 =C2=A0-nic user,model=3Dcadence_gem \
>=C2=A0 =C2=A0 =C2=A0-nic tap,ifname=3Dtap,model=3Dcadence_gem,script=3D= no \
>=C2=A0 =C2=A0 =C2=A0-display none -serial stdio \
>=C2=A0 =C2=A0 =C2=A0-chardev socket,id=3Dserial1,path=3Dserial1.sock,se= rver=3Don,wait=3Don \
>=C2=A0 =C2=A0 =C2=A0-serial chardev:serial1
>
>
> Are there other ways in qemu icicle machine supported now to pass the = u-boot and kernel?
>

Yes, it has. The capability to direct boot kernel (can be U-Boot or an
OS kernel) without HSS is currently in the Alistair's riscv-next tree and should land on qemu/master soon.

Regards,
Bin
--0000000000009b1c0605c3b8a20b-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lo9Gk-0000p6-LA for mharc-qemu-riscv@gnu.org; Tue, 01 Jun 2021 14:37:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo9Gj-0000oq-KZ for qemu-riscv@nongnu.org; Tue, 01 Jun 2021 14:37:37 -0400 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]:34410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lo9Gg-0006Zv-V0 for qemu-riscv@nongnu.org; Tue, 01 Jun 2021 14:37:37 -0400 Received: by mail-ej1-x635.google.com with SMTP id g8so14823204ejx.1 for ; Tue, 01 Jun 2021 11:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8lyh9LUX7vehsIV1GTvaa4aECYiZaAvk0/weS/g7IU=; b=WjQ8is1otZ5e7y4gucHbp9uiSntzcZEj6PfFPHX/b6GWN+2W9C1IH5ELj7IjliiGBY e/8a3QDD5j4n+iWSn5foKdeb8Y+rYhg3v/5ButM1+AFTbtfB8BfEsRoX3CZgO9Z27ykX 3wgrDYT9BpAQfjy2tdd3/8EkejxW3elnUPqafE9ke21aylVTehpQ+Yp92tzMFMTYQ4wa Pp6wYeLom8nHlXAY6MhCYDICAqj3MFr1tHQSnYrWlQ7Rei+zUnmPw+aqFY9qC27fw/8J GDmbIClHyY9Gc1v3o966Xl5I8TuV3Ad29HTIyH7V0osGodHIZpAVx74daxI7sHBK6zvw PFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8lyh9LUX7vehsIV1GTvaa4aECYiZaAvk0/weS/g7IU=; b=DZ9UWiTTCi6n3AT8nCE9Hg6MAu/LGubOuTgOUa0/D5I1bAq+PBKJ9GmkB3eYNA0jbP OBuFp1gCFDETRYz5BtSijr9qWKOUP970thtWL5rAsmgJ+wkQuj4ygX1bFy7KTmvUf2W+ jfKRE9AcGXBu1u2m9/hlGiBCUz40M0R9j2g96bCtf5/Mne0XoCzknC028lNSrB3ICfmj 4fVTlLXAkROQUGks2NwiBoOHriDSdCQxvdrv3kKOwO7Nqg+3Gz8N9cCvqGYzw86Ud/St vqglv959HFw7kMSC48xozzRYOxEe4jmVPo05xWpoEr9XJchJ5eN1L7Q+pjUuzSQTmA/v F4eA== X-Gm-Message-State: AOAM531Mp3YVbCjl3ZPtJ9ExQZl6S/nphHCjnqwdV78bjB6u02/xrP9X 9vt08uwPNc1DEAXGiHT6abQhjxCqHmnt9iTlxPpvvg== X-Google-Smtp-Source: ABdhPJzL3CtpzTNjtdrKOAw9iq1OGsosf71eYBHicC+q/xuLOJl6Z4mb411B8aZFMZEZfXXirY4zdVpv8S9aQlvsozk= X-Received: by 2002:a17:906:c1ca:: with SMTP id bw10mr31196958ejb.512.1622572653018; Tue, 01 Jun 2021 11:37:33 -0700 (PDT) MIME-Version: 1.0 References: <0CAA9018-0C42-4140-82C1-EAC80D46D359@getmailspring.com> In-Reply-To: From: Rahul Pathak Date: Wed, 2 Jun 2021 00:06:56 +0530 Message-ID: Subject: Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit To: Bin Meng Cc: Rahul Pathak , "open list:RISC-V" , Alistair Francis , "qemu-devel@nongnu.org Developers" Content-Type: multipart/alternative; boundary="0000000000009b1c0605c3b8a20b" Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=rpathak@ventanamicro.com; helo=mail-ej1-x635.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no 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: Tue, 01 Jun 2021 18:37:37 -0000 --0000000000009b1c0605c3b8a20b Content-Type: text/plain; charset="UTF-8" I swapped the serial_hd() index between the MMUART0 and MMUART1 , so my default qemu console is the MMUART1. I can see the U-Boot and Kernel logs now. I still need both serial consoles for HSS and UBoot/Kernel and will need your help to make the original qemu command line work with unix\#serial1.sock. I am unable to figure out what's wrong with unix\#serial1.sock On Tue, Jun 1, 2021 at 7:48 PM Rahul Pathak wrote: > Hi Bin, > > Thanks for the response. > > I think the issue currently is that if I keep the "wait=on" and launch > minicom on "unix\#serial1.sock" then nothing happens. > Qemu keeps waiting for the connection on serial1 and no logs for uboot and > Kernel appears on the serial1. > > Thanks > Rahul > > On Tue, Jun 1, 2021 at 7:39 PM Bin Meng wrote: > >> Hi Rahul, >> >> On Tue, Jun 1, 2021 at 11:12 AM Rahul Pathak >> wrote: >> > >> > Hi BIn,Alistair, >> > >> > I was passing the hss.elf file and it was strange that gdb after >> connecting was not letting the target to continue from gdb. >> >> This is the expected behavior if you pass an image to gdb before >> connecting to the target, as gdb will assume the debug contexts are >> the same, but it's not the case for PolarFire which has 1+4 hybrid >> configuration. >> >> > what worked was to not pass anything and then connect the to target >> then load the symbol file as hss.elf. >> > I followed the steps from the "Attaching the GDB" doc and was able to >> debug. >> > >> >> Yes, that's the correct way to debug PolarFire. >> >> > >> > For the qemu command line from the doc, I made the "wait=off" then qemu >> was not waiting for another serial connection >> > and launched the hss. >> >> You need to connect to the other serial connection otherwise QEMU does >> not start the emulation when "wait=on" >> >> > >> > >> > The problem remains is that I still do not have the u-boot and linux >> booting. The unix\#serial1.sock remains offline always. >> > These are the HSS logs - >> > >> > [0.115001] HSS_E51_Banner(): PolarFire(R) SoC Hart Software Services >> (HSS) - version 0.99.15 >> > (c) Copyright 2017-2020 Microchip Corporation. >> > >> > [0.116234] HSS_E51_Banner(): incorporating OpenSBI - version 0.6 >> > (c) Copyright 2019-2020 Western Digital Corporation. >> > >> > [0.117071] HSS_PrintBuildId(): Build ID: >> 811342a39f80176f9e2086bf963a83224b3d3a2e >> > [0.117817] HSS_PrintToolVersions(): Built with the following tools: >> > - riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0 >> >> Yeah, this log indicates that GCC 10.x works with HSS :) >> >> > - GNU ld (GNU Binutils) 2.36.1 >> > >> > [0.118760] HSS_MemTestDDRFast(): DDR size is 1 GiB >> > [0.130270] HSS_MMCInit(): Attempting to select SDCARD ... Passed >> > Press a key to enter CLI, ESC to skip >> > Timeout in 5 seconds >> > >> > ..... >> > [5.138747] HSS_TinyCLI_Parser(): CLI check timeout >> > [5.139371] IPI_QueuesInit(): Initializing IPI Queues (9000 bytes @ >> 8000e40)... >> > [5.140435] HSS_PMP_Init(): Initializing PMPs >> > [5.141093] HSS_BootInit(): Initializing Boot Image.. >> > [5.141787] getBootImageFromMMC_(): Preparing to copy from MMC to DDR ... >> > [5.142671] getBootImageFromMMC_(): Attempting to read image header >> (1552 bytes) ... >> > [5.144118] GPT_ValidateHeader(): Validated GPT Header ... >> > [5.153768] GPT_ValidatePartitionEntries(): Validated GPT Partition >> Entries ... >> > [5.155210] copyBootImageToDDR_(): Copying 436008 bytes to 0xA0000000 >> > [5.407848] copyBootImageToDDR_(): Calculated CRC32 of image in DDR is >> 795fbbea >> > [5.412058] HSS_BootInit(): boot image passed CRC >> > [5.412407] HSS_BootInit(): Boot image set name: >> "PolarFire-SoC-HSS::U-Boot" >> > [5.412951] HSS_BootInit(): Boot Image registered... >> > [5.413376] HSS_Boot_RestartCore(): called for all harts >> > [5.414295] RunStateMachine(): boot_service(u54_1)::Init -> >> boot_service(u54_1)::SetupPMP >> > [5.414812] RunStateMachine(): boot_service(u54_2)::Init -> >> boot_service(u54_2)::SetupPMP >> > [5.415207] RunStateMachine(): boot_service(u54_3)::Init -> >> boot_service(u54_3)::SetupPMP >> > [5.415631] RunStateMachine(): boot_service(u54_4)::Init -> >> boot_service(u54_4)::SetupPMP >> > [5.416107] RunStateMachine(): usbdmsc_service::init -> >> usbdmsc_service::idle >> > [5.417164] RunStateMachine(): boot_service(u54_1)::SetupPMP -> >> boot_service(u54_1)::SetupPMPComplete >> > [5.417887] RunStateMachine(): boot_service(u54_2)::SetupPMP -> >> boot_service(u54_2)::SetupPMPComplete >> > [5.418552] RunStateMachine(): boot_service(u54_3)::SetupPMP -> >> boot_service(u54_3)::SetupPMPComplete >> > [5.419890] RunStateMachine(): boot_service(u54_4)::SetupPMP -> >> boot_service(u54_4)::SetupPMPComplete >> > [23.955147] RunStateMachine(): boot_service(u54_1)::SetupPMPComplete -> >> boot_service(u54_1)::ZeroInit >> > [23.955754] RunStateMachine(): boot_service(u54_2)::SetupPMPComplete -> >> boot_service(u54_2)::ZeroInit >> > [23.956259] RunStateMachine(): boot_service(u54_3)::SetupPMPComplete -> >> boot_service(u54_3)::ZeroInit >> > [23.956757] RunStateMachine(): boot_service(u54_4)::SetupPMPComplete -> >> boot_service(u54_4)::ZeroInit >> > [23.957371] RunStateMachine(): boot_service(u54_1)::ZeroInit -> >> boot_service(u54_1)::Download >> > [23.957876] RunStateMachine(): boot_service(u54_2)::ZeroInit -> >> boot_service(u54_2)::Download >> > [23.958386] RunStateMachine(): boot_service(u54_3)::ZeroInit -> >> boot_service(u54_3)::Download >> > [23.958856] RunStateMachine(): boot_service(u54_4)::ZeroInit -> >> boot_service(u54_4)::Download >> > [23.960300] RunStateMachine(): boot_service(u54_2)::Download -> >> boot_service(u54_2)::Idle >> > [23.960723] RunStateMachine(): boot_service(u54_3)::Download -> >> boot_service(u54_3)::Idle >> > [23.961129] RunStateMachine(): boot_service(u54_4)::Download -> >> boot_service(u54_4)::Idle >> > [23.983168] RunStateMachine(): boot_service(u54_1)::Download -> >> boot_service(u54_1)::Wait >> > [23.983661] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_2:sbi_init 80200000 >> > [23.984374] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_3:sbi_init 80200000 >> > [23.985418] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_4:sbi_init 80200000 >> > [23.986783] boot_download_chunks_onExit(): >> boot_service(u54_1)::u54_1:sbi_init 80200000 >> > [23.989086] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI >> ACKs: - - >> > [23.992106] boot_wait_handler(): boot_service(u54_1)::Checking for IPI >> ACKs: ACK/IDLE ACK >> > [23.994062] RunStateMachine(): boot_service(u54_1)::Wait -> >> boot_service(u54_1)::Idle >> > >> >> Based on the above log, HSS successfully boots U-Boot already. The >> U-Boot console is on the other serial console, which I guess you might >> turn it off? >> >> > >> > One thing I overlooked in the document is that we are preparing the >> *.wic file after downloading >> > but passing the *.img in the qemu command. How to convert the wic to >> img. I couldn't see much about >> > this on the internet ? >> >> The *.wic image is the raw image. Just use it as it is. >> >> > Since U-boot currently does not boot, it seems passing the wic file >> directly is not right. Now sure here. >> > >> > qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \ >> > -bios path/to/hss.bin -sd path/to/sdcard.img \ >> > -nic user,model=cadence_gem \ >> > -nic tap,ifname=tap,model=cadence_gem,script=no \ >> > -display none -serial stdio \ >> > -chardev socket,id=serial1,path=serial1.sock,server=on,wait=on \ >> > -serial chardev:serial1 >> > >> > >> > Are there other ways in qemu icicle machine supported now to pass the >> u-boot and kernel? >> > >> >> Yes, it has. The capability to direct boot kernel (can be U-Boot or an >> OS kernel) without HSS is currently in the Alistair's riscv-next tree >> and should land on qemu/master soon. >> >> Regards, >> Bin >> > --0000000000009b1c0605c3b8a20b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I swapped the serial_hd() index between the MMUART0 and MMUART1= =C2=A0, so my default qemu console is the MMUART1.
I can see the U-Boot and= Kernel logs now.=C2=A0

I still need both serial consoles for HSS and = UBoot/Kernel and will need your help to make the original qemu command line= work with unix\#serial1.sock.
I am unable to figure out what's wrong w= ith=C2=A0unix\#serial1.sock

On Tue, Jun 1, 2021 at 7:48 PM Rahul Patha= k <rpathak= @ventanamicro.com> wrote:
Hi Bin,

Thanks for the response.=C2=A0
I think the issue currently=C2=A0is that if I keep the "wait=3Don&q= uot; and launch minicom on=C2=A0 "unix\#serial1.sock" then nothin= g happens.
Qemu keeps waiting for the connection on serial1 and no logs for= uboot and Kernel appears on the serial1.

Thanks
Rahul

=
On Tue, Ju= n 1, 2021 at 7:39 PM Bin Meng <bmeng.cn@gmail.com> wrote:
Hi Rahul,

On Tue, Jun 1, 2021 at 11:12 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:=
>
> Hi BIn,Alistair,
>
> I was passing the hss.elf file and it was strange that gdb after conne= cting was not letting the target to continue from gdb.

This is the expected behavior if you pass an image to gdb before
connecting to the target, as gdb will assume the debug contexts are
the same, but it's not the case for PolarFire which has 1+4 hybrid
configuration.

> what worked was to not pass anything and then connect the to target th= en load the symbol file as hss.elf.
> I followed the steps from the "Attaching the GDB" doc and wa= s able to debug.
>

Yes, that's the correct way to debug PolarFire.

>
> For the qemu command line from the doc, I made the "wait=3Doff&qu= ot; then qemu was not waiting for another serial connection
> and launched the hss.

You need to connect to the other serial connection otherwise QEMU does
not start the emulation when "wait=3Don"

>
>
> The problem remains is that I still do not have the u-boot and linux b= ooting. The unix\#serial1.sock remains offline always.
> These are the HSS logs -
>
> [0.115001] HSS_E51_Banner(): PolarFire(R) SoC Hart Software Services (= HSS) - version 0.99.15
> (c) Copyright 2017-2020 Microchip Corporation.
>
> [0.116234] HSS_E51_Banner(): incorporating OpenSBI - version 0.6
> (c) Copyright 2019-2020 Western Digital Corporation.
>
> [0.117071] HSS_PrintBuildId(): Build ID: 811342a39f80176f9e2086bf963a8= 3224b3d3a2e
> [0.117817] HSS_PrintToolVersions(): Built with the following tools: >=C2=A0 - riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0

Yeah, this log indicates that GCC 10.x works with HSS :)

>=C2=A0 - GNU ld (GNU Binutils) 2.36.1
>
> [0.118760] HSS_MemTestDDRFast(): DDR size is 1 GiB
> [0.130270] HSS_MMCInit(): Attempting to select SDCARD ... Passed
> Press a key to enter CLI, ESC to skip
> Timeout in 5 seconds
>
> .....
> [5.138747] HSS_TinyCLI_Parser(): CLI check timeout
> [5.139371] IPI_QueuesInit(): Initializing IPI Queues (9000 bytes @ 800= 0e40)...
> [5.140435] HSS_PMP_Init(): Initializing PMPs
> [5.141093] HSS_BootInit(): Initializing Boot Image..
> [5.141787] getBootImageFromMMC_(): Preparing to copy from MMC to DDR .= ..
> [5.142671] getBootImageFromMMC_(): Attempting to read image header (15= 52 bytes) ...
> [5.144118] GPT_ValidateHeader(): Validated GPT Header ...
> [5.153768] GPT_ValidatePartitionEntries(): Validated GPT Partition Ent= ries ...
> [5.155210] copyBootImageToDDR_(): Copying 436008 bytes to 0xA0000000 > [5.407848] copyBootImageToDDR_(): Calculated CRC32 of image in DDR is = 795fbbea
> [5.412058] HSS_BootInit():=C2=A0 boot image passed CRC
> [5.412407] HSS_BootInit(): Boot image set name: "PolarFire-SoC-HS= S::U-Boot"
> [5.412951] HSS_BootInit(): Boot Image registered...
> [5.413376] HSS_Boot_RestartCore(): called for all harts
> [5.414295] RunStateMachine(): boot_service(u54_1)::Init -> boot_ser= vice(u54_1)::SetupPMP
> [5.414812] RunStateMachine(): boot_service(u54_2)::Init -> boot_ser= vice(u54_2)::SetupPMP
> [5.415207] RunStateMachine(): boot_service(u54_3)::Init -> boot_ser= vice(u54_3)::SetupPMP
> [5.415631] RunStateMachine(): boot_service(u54_4)::Init -> boot_ser= vice(u54_4)::SetupPMP
> [5.416107] RunStateMachine(): usbdmsc_service::init -> usbdmsc_serv= ice::idle
> [5.417164] RunStateMachine(): boot_service(u54_1)::SetupPMP -> boot= _service(u54_1)::SetupPMPComplete
> [5.417887] RunStateMachine(): boot_service(u54_2)::SetupPMP -> boot= _service(u54_2)::SetupPMPComplete
> [5.418552] RunStateMachine(): boot_service(u54_3)::SetupPMP -> boot= _service(u54_3)::SetupPMPComplete
> [5.419890] RunStateMachine(): boot_service(u54_4)::SetupPMP -> boot= _service(u54_4)::SetupPMPComplete
> [23.955147] RunStateMachine(): boot_service(u54_1)::SetupPMPComplete -= > boot_service(u54_1)::ZeroInit
> [23.955754] RunStateMachine(): boot_service(u54_2)::SetupPMPComplete -= > boot_service(u54_2)::ZeroInit
> [23.956259] RunStateMachine(): boot_service(u54_3)::SetupPMPComplete -= > boot_service(u54_3)::ZeroInit
> [23.956757] RunStateMachine(): boot_service(u54_4)::SetupPMPComplete -= > boot_service(u54_4)::ZeroInit
> [23.957371] RunStateMachine(): boot_service(u54_1)::ZeroInit -> boo= t_service(u54_1)::Download
> [23.957876] RunStateMachine(): boot_service(u54_2)::ZeroInit -> boo= t_service(u54_2)::Download
> [23.958386] RunStateMachine(): boot_service(u54_3)::ZeroInit -> boo= t_service(u54_3)::Download
> [23.958856] RunStateMachine(): boot_service(u54_4)::ZeroInit -> boo= t_service(u54_4)::Download
> [23.960300] RunStateMachine(): boot_service(u54_2)::Download -> boo= t_service(u54_2)::Idle
> [23.960723] RunStateMachine(): boot_service(u54_3)::Download -> boo= t_service(u54_3)::Idle
> [23.961129] RunStateMachine(): boot_service(u54_4)::Download -> boo= t_service(u54_4)::Idle
> [23.983168] RunStateMachine(): boot_service(u54_1)::Download -> boo= t_service(u54_1)::Wait
> [23.983661] boot_download_chunks_onExit(): boot_service(u54_1)::u54_2:= sbi_init 80200000
> [23.984374] boot_download_chunks_onExit(): boot_service(u54_1)::u54_3:= sbi_init 80200000
> [23.985418] boot_download_chunks_onExit(): boot_service(u54_1)::u54_4:= sbi_init 80200000
> [23.986783] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:= sbi_init 80200000
> [23.989086] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI= ACKs: - -
> [23.992106] boot_wait_handler(): boot_service(u54_1)::Checking for IPI= ACKs: ACK/IDLE ACK
> [23.994062] RunStateMachine(): boot_service(u54_1)::Wait -> boot_se= rvice(u54_1)::Idle
>

Based on the above log, HSS successfully boots U-Boot already. The
U-Boot console is on the other serial console, which I guess you might
turn it off?

>
> One thing I overlooked in the document is that we are preparing the *.= wic file after downloading
> but passing the *.img in the qemu command. How to convert the wic to i= mg. I couldn't see much about
> this on the internet ?

The *.wic image is the raw image. Just use it as it is.

> Since U-boot currently does not boot, it seems passing the wic file di= rectly is not right. Now sure here.
>
>=C2=A0 qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
>=C2=A0 =C2=A0 =C2=A0-bios path/to/hss.bin -sd path/to/sdcard.img \
>=C2=A0 =C2=A0 =C2=A0-nic user,model=3Dcadence_gem \
>=C2=A0 =C2=A0 =C2=A0-nic tap,ifname=3Dtap,model=3Dcadence_gem,script=3D= no \
>=C2=A0 =C2=A0 =C2=A0-display none -serial stdio \
>=C2=A0 =C2=A0 =C2=A0-chardev socket,id=3Dserial1,path=3Dserial1.sock,se= rver=3Don,wait=3Don \
>=C2=A0 =C2=A0 =C2=A0-serial chardev:serial1
>
>
> Are there other ways in qemu icicle machine supported now to pass the = u-boot and kernel?
>

Yes, it has. The capability to direct boot kernel (can be U-Boot or an
OS kernel) without HSS is currently in the Alistair's riscv-next tree and should land on qemu/master soon.

Regards,
Bin
--0000000000009b1c0605c3b8a20b--