* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-05-31 9:16 ` Rahul Pathak
0 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-05-31 9:16 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, open list:RISC-V, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]
I followed the same link. I will elaborate what is happening at my end -
*First* -
Used the same versions as per the doc. Built HSS 2020.12 and used
core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
Upon executing the qemu launch command as per the doc, it's just waits for
the connection on another serial console -
info: QEMU waiting for connection on: disconnected:unix
:serial1.sock,server=on
Even if I open sudo minicom -D unix\#serial1.sock, which remains offline
always.
*Second* -
If I remove the "-chardev
socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1"
from the
qemu launch command then HSS boots but stops after sbi_init on all the
cores and put the cores in Idle -
[5.443011] boot_download_chunks_onExit():
boot_service(u54_1)::u54_1:sbi_init 80200000
[5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI ACKs:
- -
[5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI ACKs:
ACK/IDLE ACK
[5.449343] RunStateMachine(): boot_service(u54_1)::Wait ->
boot_service(u54_1)::Idle
*Third -*
If I take the latest release of HSS 2021.04 and build with gcc10, it does
not boot at all even if I remove the serial1 like in the second case.
Thanks
Rahul
On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Rahul,
>
> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com>
> wrote:
> >
> > Hi Bin,
> >
> > I was reading a github issue which you raised for the issue with HSS
> because of GCC 10.1. Its pretty old and not sure what has changed so I
> thought to ask you over email for help.
>
> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>
> > I myself is trying to make a setup to boot the microchip-icicle-kit
> Qemu machine with HSS and Yocto linux image. Currently it does not work.
>
> Could you please elaborate which part does not work? Is that Linux,
> HSS, or U-Boot?
>
> >
> > Do you know what is the right setup to make microchip-icicle-kit
> machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be
> a working combination of HSS, Linux releases plus the toolchain version
> which makes this setup work.
> >
>
> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
> only tested the Linux images released by Microchip.
> Could you please follow the instructions @
>
> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
> to see which step might be wrong on your side?
>
> Regards,
> Bin
>
[-- Attachment #2: Type: text/html, Size: 7053 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-05-31 9:16 ` Rahul Pathak
@ 2021-05-31 14:43 ` Rahul Pathak
-1 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-05-31 14:43 UTC (permalink / raw)
To: Rahul Pathak
Cc: Alistair Francis, Bin Meng, open list:RISC-V,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]
On top of that, it seems I cannot connect with the target using gdb
(gdb) target remote :1234
Remote debugging using :1234
bfd requires flen 8, but target has flen 0
Though the ABI is lp64 and ISA is rv64imac when the hss was built.
On Mon, May 31, 2021 at 7:37 PM Rahul Pathak <rpathak@ventanamicro.com>
wrote:
> I followed the same link. I will elaborate what is happening at my end -
>
> *First* -
> Used the same versions as per the doc. Built HSS 2020.12 and used
> core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
> Upon executing the qemu launch command as per the doc, it's just waits
> for the connection on another serial console -
>
> info: QEMU waiting for connection on: disconnected:unix
> :serial1.sock,server=on
>
> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline
> always.
>
> *Second* -
> If I remove the "-chardev
> socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1"
> from the
> qemu launch command then HSS boots but stops after sbi_init on all the
> cores and put the cores in Idle -
>
> [5.443011] boot_download_chunks_onExit():
> boot_service(u54_1)::u54_1:sbi_init 80200000
> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI
> ACKs: - -
> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI
> ACKs: ACK/IDLE ACK
> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait ->
> boot_service(u54_1)::Idle
>
> *Third -*
> If I take the latest release of HSS 2021.04 and build with gcc10, it does
> not boot at all even if I remove the serial1 like in the second case.
>
>
> Thanks
> Rahul
>
> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
>> Hi Rahul,
>>
>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com>
>> wrote:
>> >
>> > Hi Bin,
>> >
>> > I was reading a github issue which you raised for the issue with HSS
>> because of GCC 10.1. Its pretty old and not sure what has changed so I
>> thought to ask you over email for help.
>>
>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>
>> > I myself is trying to make a setup to boot the microchip-icicle-kit
>> Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>
>> Could you please elaborate which part does not work? Is that Linux,
>> HSS, or U-Boot?
>>
>> >
>> > Do you know what is the right setup to make microchip-icicle-kit
>> machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be
>> a working combination of HSS, Linux releases plus the toolchain version
>> which makes this setup work.
>> >
>>
>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>> only tested the Linux images released by Microchip.
>> Could you please follow the instructions @
>>
>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>> to see which step might be wrong on your side?
>>
>> Regards,
>> Bin
>>
>
[-- Attachment #2: Type: text/html, Size: 7869 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-05-31 14:43 ` Rahul Pathak
0 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-05-31 14:43 UTC (permalink / raw)
To: Rahul Pathak
Cc: Bin Meng, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]
On top of that, it seems I cannot connect with the target using gdb
(gdb) target remote :1234
Remote debugging using :1234
bfd requires flen 8, but target has flen 0
Though the ABI is lp64 and ISA is rv64imac when the hss was built.
On Mon, May 31, 2021 at 7:37 PM Rahul Pathak <rpathak@ventanamicro.com>
wrote:
> I followed the same link. I will elaborate what is happening at my end -
>
> *First* -
> Used the same versions as per the doc. Built HSS 2020.12 and used
> core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
> Upon executing the qemu launch command as per the doc, it's just waits
> for the connection on another serial console -
>
> info: QEMU waiting for connection on: disconnected:unix
> :serial1.sock,server=on
>
> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline
> always.
>
> *Second* -
> If I remove the "-chardev
> socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1"
> from the
> qemu launch command then HSS boots but stops after sbi_init on all the
> cores and put the cores in Idle -
>
> [5.443011] boot_download_chunks_onExit():
> boot_service(u54_1)::u54_1:sbi_init 80200000
> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI
> ACKs: - -
> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI
> ACKs: ACK/IDLE ACK
> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait ->
> boot_service(u54_1)::Idle
>
> *Third -*
> If I take the latest release of HSS 2021.04 and build with gcc10, it does
> not boot at all even if I remove the serial1 like in the second case.
>
>
> Thanks
> Rahul
>
> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
>> Hi Rahul,
>>
>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com>
>> wrote:
>> >
>> > Hi Bin,
>> >
>> > I was reading a github issue which you raised for the issue with HSS
>> because of GCC 10.1. Its pretty old and not sure what has changed so I
>> thought to ask you over email for help.
>>
>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>
>> > I myself is trying to make a setup to boot the microchip-icicle-kit
>> Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>
>> Could you please elaborate which part does not work? Is that Linux,
>> HSS, or U-Boot?
>>
>> >
>> > Do you know what is the right setup to make microchip-icicle-kit
>> machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be
>> a working combination of HSS, Linux releases plus the toolchain version
>> which makes this setup work.
>> >
>>
>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>> only tested the Linux images released by Microchip.
>> Could you please follow the instructions @
>>
>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>> to see which step might be wrong on your side?
>>
>> Regards,
>> Bin
>>
>
[-- Attachment #2: Type: text/html, Size: 7869 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-05-31 14:43 ` Rahul Pathak
@ 2021-05-31 22:48 ` Alistair Francis
-1 siblings, 0 replies; 19+ messages in thread
From: Alistair Francis @ 2021-05-31 22:48 UTC (permalink / raw)
To: Rahul Pathak
Cc: open list:RISC-V, Bin Meng, Alistair Francis,
qemu-devel@nongnu.org Developers, Rahul Pathak
On Tue, Jun 1, 2021 at 12:43 AM Rahul Pathak <rpathakmailbox@gmail.com> wrote:
>
> On top of that, it seems I cannot connect with the target using gdb
>
> (gdb) target remote :1234
> Remote debugging using :1234
> bfd requires flen 8, but target has flen 0
>
> Though the ABI is lp64 and ISA is rv64imac when the hss was built.
Strange, how are you building GDB?
Alistair
>
> On Mon, May 31, 2021 at 7:37 PM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>>
>> I followed the same link. I will elaborate what is happening at my end -
>>
>> First -
>> Used the same versions as per the doc. Built HSS 2020.12 and used core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
>> Upon executing the qemu launch command as per the doc, it's just waits for the connection on another serial console -
>>
>> info: QEMU waiting for connection on: disconnected:unix:serial1.sock,server=on
>>
>> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline always.
>>
>> Second -
>> If I remove the "-chardev socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1" from the
>> qemu launch command then HSS boots but stops after sbi_init on all the cores and put the cores in Idle -
>>
>> [5.443011] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:sbi_init 80200000
>> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI ACKs: - -
>> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI ACKs: ACK/IDLE ACK
>> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait -> boot_service(u54_1)::Idle
>>
>> Third -
>> If I take the latest release of HSS 2021.04 and build with gcc10, it does not boot at all even if I remove the serial1 like in the second case.
>>
>>
>> Thanks
>> Rahul
>>
>> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> Hi Rahul,
>>>
>>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>>> >
>>> > Hi Bin,
>>> >
>>> > I was reading a github issue which you raised for the issue with HSS because of GCC 10.1. Its pretty old and not sure what has changed so I thought to ask you over email for help.
>>>
>>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>>
>>> > I myself is trying to make a setup to boot the microchip-icicle-kit Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>>
>>> Could you please elaborate which part does not work? Is that Linux,
>>> HSS, or U-Boot?
>>>
>>> >
>>> > Do you know what is the right setup to make microchip-icicle-kit machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be a working combination of HSS, Linux releases plus the toolchain version which makes this setup work.
>>> >
>>>
>>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>>> only tested the Linux images released by Microchip.
>>> Could you please follow the instructions @
>>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>>> to see which step might be wrong on your side?
>>>
>>> Regards,
>>> Bin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-05-31 22:48 ` Alistair Francis
0 siblings, 0 replies; 19+ messages in thread
From: Alistair Francis @ 2021-05-31 22:48 UTC (permalink / raw)
To: Rahul Pathak
Cc: Rahul Pathak, Alistair Francis, Bin Meng, open list:RISC-V,
qemu-devel@nongnu.org Developers
On Tue, Jun 1, 2021 at 12:43 AM Rahul Pathak <rpathakmailbox@gmail.com> wrote:
>
> On top of that, it seems I cannot connect with the target using gdb
>
> (gdb) target remote :1234
> Remote debugging using :1234
> bfd requires flen 8, but target has flen 0
>
> Though the ABI is lp64 and ISA is rv64imac when the hss was built.
Strange, how are you building GDB?
Alistair
>
> On Mon, May 31, 2021 at 7:37 PM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>>
>> I followed the same link. I will elaborate what is happening at my end -
>>
>> First -
>> Used the same versions as per the doc. Built HSS 2020.12 and used core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
>> Upon executing the qemu launch command as per the doc, it's just waits for the connection on another serial console -
>>
>> info: QEMU waiting for connection on: disconnected:unix:serial1.sock,server=on
>>
>> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline always.
>>
>> Second -
>> If I remove the "-chardev socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1" from the
>> qemu launch command then HSS boots but stops after sbi_init on all the cores and put the cores in Idle -
>>
>> [5.443011] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:sbi_init 80200000
>> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI ACKs: - -
>> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI ACKs: ACK/IDLE ACK
>> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait -> boot_service(u54_1)::Idle
>>
>> Third -
>> If I take the latest release of HSS 2021.04 and build with gcc10, it does not boot at all even if I remove the serial1 like in the second case.
>>
>>
>> Thanks
>> Rahul
>>
>> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> Hi Rahul,
>>>
>>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>>> >
>>> > Hi Bin,
>>> >
>>> > I was reading a github issue which you raised for the issue with HSS because of GCC 10.1. Its pretty old and not sure what has changed so I thought to ask you over email for help.
>>>
>>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>>
>>> > I myself is trying to make a setup to boot the microchip-icicle-kit Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>>
>>> Could you please elaborate which part does not work? Is that Linux,
>>> HSS, or U-Boot?
>>>
>>> >
>>> > Do you know what is the right setup to make microchip-icicle-kit machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be a working combination of HSS, Linux releases plus the toolchain version which makes this setup work.
>>> >
>>>
>>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>>> only tested the Linux images released by Microchip.
>>> Could you please follow the instructions @
>>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>>> to see which step might be wrong on your side?
>>>
>>> Regards,
>>> Bin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-05-31 14:43 ` Rahul Pathak
@ 2021-06-01 2:36 ` Bin Meng
-1 siblings, 0 replies; 19+ messages in thread
From: Bin Meng @ 2021-06-01 2:36 UTC (permalink / raw)
To: Rahul Pathak
Cc: Alistair Francis, open list:RISC-V,
qemu-devel@nongnu.org Developers, Rahul Pathak
Hi Rahul,
On Mon, May 31, 2021 at 10:43 PM Rahul Pathak <rpathakmailbox@gmail.com> wrote:
>
> On top of that, it seems I cannot connect with the target using gdb
>
> (gdb) target remote :1234
> Remote debugging using :1234
> bfd requires flen 8, but target has flen 0
>
> Though the ABI is lp64 and ISA is rv64imac when the hss was built.
>
Did you feed gdb the image you wanted to debug before "target remote:"?
The PolarFire SoC has 1+4 HARTs and you should follow the instructions
@ https://wiki.qemu.org/Documentation/Platforms/RISCV#Attaching_GDB to
do the debug.
Regards,
Bin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-06-01 2:36 ` Bin Meng
0 siblings, 0 replies; 19+ messages in thread
From: Bin Meng @ 2021-06-01 2:36 UTC (permalink / raw)
To: Rahul Pathak
Cc: Rahul Pathak, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
Hi Rahul,
On Mon, May 31, 2021 at 10:43 PM Rahul Pathak <rpathakmailbox@gmail.com> wrote:
>
> On top of that, it seems I cannot connect with the target using gdb
>
> (gdb) target remote :1234
> Remote debugging using :1234
> bfd requires flen 8, but target has flen 0
>
> Though the ABI is lp64 and ISA is rv64imac when the hss was built.
>
Did you feed gdb the image you wanted to debug before "target remote:"?
The PolarFire SoC has 1+4 HARTs and you should follow the instructions
@ https://wiki.qemu.org/Documentation/Platforms/RISCV#Attaching_GDB to
do the debug.
Regards,
Bin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-06-01 2:36 ` Bin Meng
@ 2021-06-01 3:11 ` Rahul Pathak
-1 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 3:11 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Rahul Pathak, open list:RISC-V,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 6301 bytes --]
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.
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.
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.
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
- 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
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 ?
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?
Thanks
Rahul
On Tue, Jun 1, 2021 at 8:06 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Rahul,
>
> On Mon, May 31, 2021 at 10:43 PM Rahul Pathak <rpathakmailbox@gmail.com>
> wrote:
> >
> > On top of that, it seems I cannot connect with the target using gdb
> >
> > (gdb) target remote :1234
> > Remote debugging using :1234
> > bfd requires flen 8, but target has flen 0
> >
> > Though the ABI is lp64 and ISA is rv64imac when the hss was built.
> >
>
> Did you feed gdb the image you wanted to debug before "target remote:"?
>
> The PolarFire SoC has 1+4 HARTs and you should follow the instructions
> @ https://wiki.qemu.org/Documentation/Platforms/RISCV#Attaching_GDB to
> do the debug.
>
> Regards,
> Bin
>
[-- Attachment #2: Type: text/html, Size: 16346 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-06-01 3:11 ` Rahul Pathak
0 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 3:11 UTC (permalink / raw)
To: Bin Meng
Cc: Rahul Pathak, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 6301 bytes --]
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.
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.
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.
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
- 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
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 ?
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?
Thanks
Rahul
On Tue, Jun 1, 2021 at 8:06 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Rahul,
>
> On Mon, May 31, 2021 at 10:43 PM Rahul Pathak <rpathakmailbox@gmail.com>
> wrote:
> >
> > On top of that, it seems I cannot connect with the target using gdb
> >
> > (gdb) target remote :1234
> > Remote debugging using :1234
> > bfd requires flen 8, but target has flen 0
> >
> > Though the ABI is lp64 and ISA is rv64imac when the hss was built.
> >
>
> Did you feed gdb the image you wanted to debug before "target remote:"?
>
> The PolarFire SoC has 1+4 HARTs and you should follow the instructions
> @ https://wiki.qemu.org/Documentation/Platforms/RISCV#Attaching_GDB to
> do the debug.
>
> Regards,
> Bin
>
[-- Attachment #2: Type: text/html, Size: 16346 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-06-01 3:11 ` Rahul Pathak
@ 2021-06-01 14:09 ` Bin Meng
-1 siblings, 0 replies; 19+ messages in thread
From: Bin Meng @ 2021-06-01 14:09 UTC (permalink / raw)
To: Rahul Pathak
Cc: Alistair Francis, Rahul Pathak, open list:RISC-V,
qemu-devel@nongnu.org Developers
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 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-06-01 14:09 ` Bin Meng
0 siblings, 0 replies; 19+ messages in thread
From: Bin Meng @ 2021-06-01 14:09 UTC (permalink / raw)
To: Rahul Pathak
Cc: Rahul Pathak, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
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 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-06-01 14:09 ` Bin Meng
@ 2021-06-01 14:18 ` Rahul Pathak
-1 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 14:18 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Rahul Pathak, open list:RISC-V,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 7311 bytes --]
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 <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
> 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
>
[-- Attachment #2: Type: text/html, Size: 9054 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-06-01 14:18 ` Rahul Pathak
0 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 14:18 UTC (permalink / raw)
To: Bin Meng
Cc: Rahul Pathak, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 7311 bytes --]
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 <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
> 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
>
[-- Attachment #2: Type: text/html, Size: 9054 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-06-01 14:18 ` Rahul Pathak
@ 2021-06-01 18:36 ` Rahul Pathak
-1 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 18:36 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Rahul Pathak, open list:RISC-V,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 7955 bytes --]
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 <rpathak@ventanamicro.com>
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 <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
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 10185 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-06-01 18:36 ` Rahul Pathak
0 siblings, 0 replies; 19+ messages in thread
From: Rahul Pathak @ 2021-06-01 18:36 UTC (permalink / raw)
To: Bin Meng
Cc: Rahul Pathak, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 7955 bytes --]
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 <rpathak@ventanamicro.com>
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 <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
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 10185 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
2021-05-31 9:16 ` Rahul Pathak
@ 2021-05-31 22:48 ` Alistair Francis
-1 siblings, 0 replies; 19+ messages in thread
From: Alistair Francis @ 2021-05-31 22:48 UTC (permalink / raw)
To: Rahul Pathak
Cc: Alistair Francis, Bin Meng, open list:RISC-V,
qemu-devel@nongnu.org Developers
On Tue, Jun 1, 2021 at 12:06 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>
> I followed the same link. I will elaborate what is happening at my end -
>
> First -
> Used the same versions as per the doc. Built HSS 2020.12 and used core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
> Upon executing the qemu launch command as per the doc, it's just waits for the connection on another serial console -
>
> info: QEMU waiting for connection on: disconnected:unix:serial1.sock,server=on
That seems like you are passing an argument to QEMU to expose a
socket. You don't need to do that and can instead use stdio.
For the runqemu command in OE you can do that with `runqemu nographic`
Alistair
>
> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline always.
>
> Second -
> If I remove the "-chardev socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1" from the
> qemu launch command then HSS boots but stops after sbi_init on all the cores and put the cores in Idle -
>
> [5.443011] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:sbi_init 80200000
> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI ACKs: - -
> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI ACKs: ACK/IDLE ACK
> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait -> boot_service(u54_1)::Idle
>
> Third -
> If I take the latest release of HSS 2021.04 and build with gcc10, it does not boot at all even if I remove the serial1 like in the second case.
>
>
> Thanks
> Rahul
>
> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Rahul,
>>
>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>> >
>> > Hi Bin,
>> >
>> > I was reading a github issue which you raised for the issue with HSS because of GCC 10.1. Its pretty old and not sure what has changed so I thought to ask you over email for help.
>>
>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>
>> > I myself is trying to make a setup to boot the microchip-icicle-kit Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>
>> Could you please elaborate which part does not work? Is that Linux,
>> HSS, or U-Boot?
>>
>> >
>> > Do you know what is the right setup to make microchip-icicle-kit machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be a working combination of HSS, Linux releases plus the toolchain version which makes this setup work.
>> >
>>
>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>> only tested the Linux images released by Microchip.
>> Could you please follow the instructions @
>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>> to see which step might be wrong on your side?
>>
>> Regards,
>> Bin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: HSS Issue with GCC 10, Qemu Setup for microchip-icicle-kit
@ 2021-05-31 22:48 ` Alistair Francis
0 siblings, 0 replies; 19+ messages in thread
From: Alistair Francis @ 2021-05-31 22:48 UTC (permalink / raw)
To: Rahul Pathak
Cc: Bin Meng, open list:RISC-V, Alistair Francis,
qemu-devel@nongnu.org Developers
On Tue, Jun 1, 2021 at 12:06 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>
> I followed the same link. I will elaborate what is happening at my end -
>
> First -
> Used the same versions as per the doc. Built HSS 2020.12 and used core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.
> Upon executing the qemu launch command as per the doc, it's just waits for the connection on another serial console -
>
> info: QEMU waiting for connection on: disconnected:unix:serial1.sock,server=on
That seems like you are passing an argument to QEMU to expose a
socket. You don't need to do that and can instead use stdio.
For the runqemu command in OE you can do that with `runqemu nographic`
Alistair
>
> Even if I open sudo minicom -D unix\#serial1.sock, which remains offline always.
>
> Second -
> If I remove the "-chardev socket,id=serial1,path=serial1.sock,server=on,wait=on -serial chardev:serial1" from the
> qemu launch command then HSS boots but stops after sbi_init on all the cores and put the cores in Idle -
>
> [5.443011] boot_download_chunks_onExit(): boot_service(u54_1)::u54_1:sbi_init 80200000
> [5.444960] boot_wait_onEntry(): boot_service(u54_1)::Checking for IPI ACKs: - -
> [5.447962] boot_wait_handler(): boot_service(u54_1)::Checking for IPI ACKs: ACK/IDLE ACK
> [5.449343] RunStateMachine(): boot_service(u54_1)::Wait -> boot_service(u54_1)::Idle
>
> Third -
> If I take the latest release of HSS 2021.04 and build with gcc10, it does not boot at all even if I remove the serial1 like in the second case.
>
>
> Thanks
> Rahul
>
> On Mon, May 31, 2021 at 8:19 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Rahul,
>>
>> On Mon, May 31, 2021 at 1:08 AM Rahul Pathak <rpathak@ventanamicro.com> wrote:
>> >
>> > Hi Bin,
>> >
>> > I was reading a github issue which you raised for the issue with HSS because of GCC 10.1. Its pretty old and not sure what has changed so I thought to ask you over email for help.
>>
>> The HSS issue of GCC 10.1 was already fixed in the HSS mainline.
>>
>> > I myself is trying to make a setup to boot the microchip-icicle-kit Qemu machine with HSS and Yocto linux image. Currently it does not work.
>>
>> Could you please elaborate which part does not work? Is that Linux,
>> HSS, or U-Boot?
>>
>> >
>> > Do you know what is the right setup to make microchip-icicle-kit machine with HSS.bin and Yocto linux work on Qemu?. Probably there will be a working combination of HSS, Linux releases plus the toolchain version which makes this setup work.
>> >
>>
>> I have not tried Yocto Linux yet with Microchip Icicle Kit on QEMU. I
>> only tested the Linux images released by Microchip.
>> Could you please follow the instructions @
>> https://qemu.readthedocs.io/en/latest/system/riscv/microchip-icicle-kit.html
>> to see which step might be wrong on your side?
>>
>> Regards,
>> Bin
^ permalink raw reply [flat|nested] 19+ messages in thread