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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Sep 2021 16:10:14 +0200
From:   Andre Muller <andre.muller@....de>
To:     Rob Herring <robh+dt@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [Bisected Regression] OLPC XO-1.5: Internal drive and SD card
 (mmcblk*) gone since commit ea718c699055

On 09/09/2021 00.31, Rob Herring wrote:
> On Tue, Sep 7, 2021 at 10:15 PM Saravana Kannan <saravanak@...gle.com> wrote:
>>
>> On Tue, Sep 7, 2021 at 7:12 PM Andre Muller <andre.muller@....de> wrote:
>>>
>>> On 08/09/2021 00.05, Saravana Kannan wrote:
>>>> On Sun, Sep 5, 2021 at 1:15 AM Andre Muller <andre.muller@....de> 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.

Uh-oh, my bad...

The bad case says
# cat devices_deferred
0000:00:0c.0

That's the SD Host controller.

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

Ah, thanks. I never knew about the DT in there...
XO-1.5_dump.dts is attached.

>
> 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);
>> +
>

OK. The dmesg with debug info is attached as well (for the broken case).

Thanks to both of you,
Andre


> Please add something like this that can be enabled easily with dynamic debug.
>
> Rob
>
> [1] https://pastebin.com/um0kAZym
>


Download attachment "XO-1.5_dump.dts" of type "audio/vnd.dts" (18357 bytes)

View attachment "config-XO-1.5-5.11+" of type "text/plain" (111620 bytes)

View attachment "dmesg.debug.bad" of type "text/plain" (99829 bytes)