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

[Saravana Kannan]

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.

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?

>
>
> 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.

>
> 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);
+
        link->supplier = sup;
        INIT_LIST_HEAD(&link->s_hook);
        link->consumer = con;

Thanks,
Saravana