qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu icicle kit es


From: Bin Meng
Subject: Re: qemu icicle kit es
Date: Fri, 13 Jan 2023 08:35:11 +0800

On Fri, Jan 13, 2023 at 2:03 AM Conor Dooley <conor@kernel.org> wrote:
>
> +CC Bin Meng
>
> On Thu, Jan 12, 2023 at 10:52:39AM +0100, stage TC wrote:
> > Le mer. 11 janv. 2023 à 17:40, Conor Dooley <conor@kernel.org> a écrit :
> > >On Wed, Jan 11, 2023 at 03:21:26PM +0100, stage TC wrote:
> > >> Hello,
> > >> Sorry in advance if this is not the right way to do it but I'm a student
> > >> and not very used to this kind of stuff (first mailing list).
> >
> > >Don't worry, you are doing fine :)
>
> One thing to note, this mail appears to be in html form. I am not sure
> what the QEMU mailing lists stance on html mail is, but on other lists
> it is frowned upon.
> Just an FYI if you end up using other mailing lists in the future.
>
> > >> I'm trying to run qemu for the Microchip PolarFire SoC Icicle kit but I'm
> > >> facing a few issues and the wiki page about that seems obsolete.
> >
> > >I must admit, it's a long time since I tried to use a v2020.x release of
> > >any MPFS software. Last time I did give the steps in the docs a go,
> > >with a suitably vintage version of QEMU, things worked as expected.
> > >However, using more recent versions of QEMU I ran into some problems
> > >with the sd/mmc emulation & never get into U-Boot.
> >
> > I was using qemu 7.1 and then came back to qemu 5.2 to try using the same
> > version as the wiki, does the version of qemu have an impact ?
>
> In theory, it shouldn't. I was just suggesting that you use the version
> in the Wiki as it had obviously been tested at some point in time.
>
> > Should I use a more recent one ?
>
> Ideally yes, but, like you, I wasn't able to get the example to boot on
> recent versions. We had some patches internally that supposedly got
> things working for later versions of QEMU but I never got them to work
> unfortunately.
>
> Bin Meng, you're listed as a supporter (in master anyway) but is that
> still accurate? I figure there's a good chance it isn't anymore?
> Have you tested the platform from HSS init at all lately?

Yes, I am still maintaining the QEMU PolarFire SoC. The WiKi page
listed the exact HSS version I tested and if it doesn't, it should be
a regression in QEMU. If yes, I would like to have a look at that.

Running more recent HSS is known to break, because QEMU does not
follow up quite closely with the HSS implementation as HSS has evolved
quite quickly in the past.

>
> > >> I follow almost exactly what the wiki does (except I use a terminal as a
> > >> tty instead of the socket bc it didn't work) but my HSS won't boot on
> > >> versions more recent than 2020.10 or 0.99.12.
> >
> > >What does "my HSS won't boot" mean? E.g:
> > >- Does the MICROCHIP logo banner appear (if it existed back then!)?
> > >   If it didnt, the version string I think was.
> > >- Does the HSS console appear?
> > >- Does it fail to launch the next bootloader stage?
> >
> > With the 0.99.12 and the v2021.02 image the MICROCHIP logo banner appears
> > with the HSS console and the next bootloader stage seems to launch
> > correctly (see the logs in the attachment).
>
> There is no attachment :(
>
> > With the 0.99.15 the MICROCHIP logo banner appears but the HSS console is
> > stuck at "Selecting SD Card ..."
> > With a more recent one nothing appends.
>
> Right. I think this one is because a change was made to the FPGA
> bitstream around this time so that the eMMC and SD card are muxxed using
> a register in the FPGA fabric rather than a GPIO.
>
> Which version of QEMU is this? I can try and see if the emulation is
> missing (or broken). That sort of thing I do have time for (anything I
> do for QEMU is in my spare time).
>
> > >> However I can't find any image compatible for versions older than 2020.10
> > >> or 0.99.12 (mines hang at "starting kernel ...".
> >
> > >By that do you mean you cannot find a pre-built yocto image? I am not
> > >sure that there are any that pre-date the one linked in the wiki that
> > >are still available, as those on GitHub only go back as far as v2021.02
> >
> > Yes, that is what I was talking about. The link in the wiki is obsolete and
> > the v2021.2 (the only one left with an sdcard specific version) looks to
> > have been tested on HSS 0.99.15.
>
> I'm not sure if there's much point trying an older version of the image
> than that that was mentioned in the wiki anyway.
>
> Because it's an FPGA, changes can (*and have been*) be made to the
> bitstream that made it incompatible with the emulation of the SoC in
> QEMU - memory layout, etc - so I'd likely not suggest using newer
> versions either!
>
> > >> Is there any newer version of the tutorial ? Or does anyone have an idea
> > on
> > >> how to deal with this issue and use qemu for newer versions of the HSS ?
> >
> > >I do my testing with something like:
> > >$(QEMU)/qemu-system-riscv64 \
> > >        -M microchip-icicle-kit \
> > >        -m 2G -smp 5 \
> > >        -kernel $(vmlinux_bin) \
> > >        -dtb $(devkit).dtb \
> > >        -initrd $(initramfs) \
> > >        -display none \
> > >        -serial null \
> > >        -serial stdio
> >
> > >This loads a kernel directly rather than using the HSS - for recent
> > >versions of the HSS, implementations of some peripherals need to be
> > >added, for example, it checks things like the cache configuration
> > >during boot, which are not emulated in QEMU.
> >
> > >For that reason, I've stuck with doing direct kernel boots. Linux
> > >v6.0.18 (and the associated devicetree) is the most recent combination
> > >that I have booted unmodified using the master branch of QEMU using
> > >this method.
> >
> > Thanks, I will try to study and use this method, it may be useful.
> >
> > >More recent (linux) kernels come with a device tree that will require
> > >changes in QEMU to support & I have unfortunately not had the time
> > >to work on that recently.
> > >Sorry that I am really of no help to you.
> >
> > It helps me at least to know that this is not just something easy that I'm
> > not able to do for no reason. Thanks.
>
> Yeah, I am sorry :/
>

Regards,
Bin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]