Re: [Bisected Regression] OLPC XO-1.5: Internal drive and SD card (mmcblk*) gone since commit ea718c699055

[Rob Herring]

On Tue, Sep 7, 2021 at 10:15 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
>
> On Tue, Sep 7, 2021 at 7:12 PM Andre Muller <andre.muller@xxxxxx> wrote:
> >
> > On 08/09/2021 00.05, Saravana Kannan wrote:
> > > On Sun, Sep 5, 2021 at 1:15 AM Andre Muller <andre.muller@xxxxxx> wrote:
> > >>
> > >> With linux-5.13 and linux-5.14, the internal drive and SD card reader are gone from the XO-1.5. I bisected the issue to come up with ea718c699055:
> > >>
> > >> # first bad commit: [ea718c699055c8566eb64432388a04974c43b2ea] Revert "Revert "driver core: Set fw_devlink=on by default""
> > >>
> > >> The /dev/mmcblk* nodes are not generated since this patch.
> > >>
> > >> Please find the output of lspsi -vv and lshw below.
> > >>
> > >> I will be happy to provide more info and/or test patches.
> > >
> > > Hi Andre,
> > >
> > > Can you point me to the dts file in upstream that corresponds to this system?
> > >
> > > Also, if you can give the output of:
> > > cat /sys/kernel/debug/devices_deferred
> >
> > Hi Saravana,
> >
> >
> > /sys/kernel/debug/devices_deferred is empty.
> > I used the last good commit b6f617.
>
> Sorry, I wanted that with the bad commit.
>
> >
> > The XO-1.5 has an x86 compatible VIA C7 processor.
> > It uses the VX855 chip for about all I/O tasks, including SDIO.
> > I am not aware of a device tree file for it.
> >
> > It is a bit of a strange beast, it uses OFW to initialize the hardware and provide a FORTH shell.
> > Which also is the boot manager, configured via FORTH scripts.
> >
> >  From the linux side of the fence, dmesg's line 2 is:
> >
> > "OFW detected in memory, cif @ 0xff83ae68 (reserving top 8MB)"
> >
> > AIUI, this mechanism is used in lieu of a device tree file, like UEFI on most x86 hardware.
> > But my understanding of device trees is severely limited, I might be allwrong.
>
> Uhh... I'm so confused. If Linux doesn't use OF, then none of the code
> enabled by fw_devlink=on should be executed.

Linux does, but maybe not for memory (like UEFI on arm64).

> The only thing that might remotely even execute is:
> efifb_add_links() in drivers/firmware/efi/efi-init.c
>
> If you want you can just do an early return 0; in that to see if it
> makes a difference (unlikely).
>
> Rob, Do you know what's going on with OLPC and DT?

Not really. I have an XO-1 DT dump[1]. It's probably a similar looking
DT though. It's pretty ancient lacking anything we've invented for DT
in the last 10 years. There's not really much to it as about the only
phandle I see is for interrupts.

> > Anyway, the firmware source is here:
> > http://dev.laptop.org/git/users/quozl/openfirmware/
> >
> > This file is the closest dt-analogous thing for the XO-1.5 I can find therein:
> > cpu/x86/pc/olpc/via/devices.fth
>
> That file is all gibberish to me.

Running this on a booted system would help:

dtc -f -I fs -O dts /proc/device-tree > dump.dts

If you don't have dtc on the system, then you'll have to zip up
/proc/device-tree contents and run dtc elsewhere (or just post that).

> > My machine runs the latest version:
> > http://wiki.laptop.org/go/OLPC_Firmware_q3c17
> >
> > The XO-1.5 hardware specs are here:
> > http://wiki.laptop.org/images/f/f0/CL1B_Hdwe_Design_Spec.pdf
> > http://wiki.laptop.org/go/Hardware_specification_1.5
> >
> > Would the .config or dmesg help?
>
> At this point, why not? When you do send them, please send them as
> attachments and not inline.
>
> Also, when you collect the dmesg logs, the following could help:
> Enable the existing dev_dbg logs in these functions:
> device_link_add()
> device_links_check_suppliers()
>
> And add the following log to fwnode_link_add():
> +++ b/drivers/base/core.c
> @@ -87,6 +87,8 @@ int fwnode_link_add(struct fwnode_handle *con,
> struct fwnode_handle *sup)
>                 goto out;
>         }
>
> +       pr_info("Link fwnode %pfwP as a consumer of fwnode %pfwP\n", con, sup);
> +

Please add something like this that can be enabled easily with dynamic debug.

Rob

[1] https://pastebin.com/um0kAZym