Re: [Qemu-arm] Assigning sd-card to specific SD-bus with Sabrelite Machine

Re: [Qemu-arm] Assigning sd-card to specific SD-bus with Sabrelite Machine

[Peter Maydell]

On Thu, 17 Sep 2020 at 19:21, David Aghaian
<David.Aghaian@panasonic.aero> wrote:
> Having a real difficult time determining whether or not I can use qemu (arm) with the Sabrelite machine type to be able to assign an sd-card to one of the 4 available sd-bus slots. Currently, no matter what combination of arguments I provide, it will always fall on the first bus (see screenshot).

> Is there any way with QEMU to attach the card specifically to the last sd-bus slot? It should be noted I was able to achieve the expected behavior after patching QEMU itself with the following change but I’d prefer to not have to modify the tool itself.

This ought to work, but I think there is a bug in the QEMU model
of this board which means it does not.

> diff qemu-5.1.0.orig/hw/sd/sdhci.c qemu-5.1.0/hw/sd/sdhci.c
> 1311a1312,1314
> >     static int index=0;
> >     char name[64];
> >     sprintf(name, "sd-bus.%d", index++);
> 1313c1316
> <                         TYPE_SDHCI_BUS, DEVICE(s), "sd-bus");
> ---
> >                         TYPE_SDHCI_BUS, DEVICE(s), name);

Thanks for the suggested patch -- this was a big clue about
what the problem was.

sdhci.c isn't really the best place for this to be done -- this is
the model of the device itself, and the name of the bus as part
of the device should be 'sd-bus'. The right place to fix the
bug, I think, is in the hw/arm/fsl-imx*.c files, which are the
implementation of the SoC object. There we should be creating
aliases on the SoC for the various SD buses (there's an example
of this in hw/arm/xlnx-zynqmp.c), and the aliases can all have
different names so they're usable from the command line.

thanks
-- PMM

Re: [Qemu-arm] Assigning sd-card to specific SD-bus with Sabrelite Machine

[David Aghaian]

EDIT: Resending as reply-all

Hey Peter,


Appreciate the prompt response. Is there a particular reason why you were proposing that the modification be made to the fsl-imx* files as opposed to the "sabrelite.c" file? I was looking very briefly at the files you mentioned and I believe the line that would have to be added (basing it off the reference source you provided) would be:


Inside: fsl-imx25.c

/* Alias controller SD bus to the SoC itself */
bus_name = g_strdup_printf("sd-bus%d", i);
object_property_add_alias(OBJECT(&s->esdhc[i]), bus_name, sdhci, "sd-bus");
g_free(bus_name);

to be added just under line 251 (during initialization of the SDHC devices). I do not see the same initialization of SDHC devices for those one of the fsl files you mentioned (fsl-imx31).

Best,
David

On 9/17/20, 12:54 PM, "Peter Maydell" <peter.maydell@linaro.org> wrote:

    EXTERNAL EMAIL: This email originated from a sender outside of the organization. Use caution when responding to requests, clicking links, or opening attachments.

    ----------------------------------------------------------------------
    On Thu, 17 Sep 2020 at 19:21, David Aghaian
    <David.Aghaian@panasonic.aero> wrote:
    > Having a real difficult time determining whether or not I can use qemu (arm) with the Sabrelite machine type to be able to assign an sd-card to one of the 4 available sd-bus slots. Currently, no matter what combination of arguments I provide, it will always fall on the first bus (see screenshot).

    > Is there any way with QEMU to attach the card specifically to the last sd-bus slot? It should be noted I was able to achieve the expected behavior after patching QEMU itself with the following change but I’d prefer to not have to modify the tool itself.

    This ought to work, but I think there is a bug in the QEMU model
    of this board which means it does not.

    > diff qemu-5.1.0.orig/hw/sd/sdhci.c qemu-5.1.0/hw/sd/sdhci.c
    > 1311a1312,1314
    > >     static int index=0;
    > >     char name[64];
    > >     sprintf(name, "sd-bus.%d", index++);
    > 1313c1316
    > <                         TYPE_SDHCI_BUS, DEVICE(s), "sd-bus");
    > ---
    > >                         TYPE_SDHCI_BUS, DEVICE(s), name);

    Thanks for the suggested patch -- this was a big clue about
    what the problem was.

    sdhci.c isn't really the best place for this to be done -- this is
    the model of the device itself, and the name of the bus as part
    of the device should be 'sd-bus'. The right place to fix the
    bug, I think, is in the hw/arm/fsl-imx*.c files, which are the
    implementation of the SoC object. There we should be creating
    aliases on the SoC for the various SD buses (there's an example
    of this in hw/arm/xlnx-zynqmp.c), and the aliases can all have
    different names so they're usable from the command line.

    thanks
    -- PMM