Searching for firmware timeout cause

[Stefan Wahren]

[add Phil & Raspberry Pi list, drop lkml]

Am 16.05.25 um 16:41 schrieb Etienne Buira:
> On Fri, May 16, 2025 at 01:17:41PM +0200, Stefan Wahren wrote:
>> Am 16.05.25 um 00:27 schrieb Etienne Buira:
>>> Hi Stefan
>>>
>>> On Thu, May 15, 2025 at 07:48:04PM +0200, Stefan Wahren wrote:
>>>> Hi Etienne,
>>>>
>>>> Am 15.05.25 um 13:48 schrieb Etienne Buira:
>>>>> On Thu, May 15, 2025 at 12:31:38PM +0200, Stefan Wahren wrote:
>>>>>> Am 15.05.25 um 11:44 schrieb Etienne Buira:
>>>>>>> Hi Stefan, and thank you for your interest.
>>>>>>>
>>>>>>> On Thu, May 15, 2025 at 09:42:43AM +0200, Stefan Wahren wrote:
>>>>>>>> Hi Etienne,
>>>>>>>>
>>>>>>>> Am 15.05.25 um 08:41 schrieb Etienne Buira:
>>>>>>>>> On Wed, May 14, 2025 at 06:20:32PM +0200, Stefan Wahren wrote:
>>>>>>>>>> Hi Etienne,
>>>>>>>>>>
>>>>>>>>>> Am 12.05.25 um 18:30 schrieb Etienne Buira:
>>>>>>>>> ../..
>>>>>>>>>> Out of curiosity and because i never saw this issue, could you please
>>>>>>>>>> provide more details?
>>>>>>>>>> There is nothing connected to HDMI 0 & 1 ?
>>>>>>>>>> Which firmware version are you running?
>>>>>>>> Please provide the dmesg output, so we can extract the firmware version.
>>>>>>> Firmware version is 2025-02-17T20:03:07, i also attach the full gzipped
>>>>>>> dmesg, as long as a patch of extra traces used.
>>>>>>> I did not specifically test other firmware versions for the timeout
>>>>>>> issue (but i did for video output).
>>>>>> Thanks, i'll try to reproduce.
>>>>>>
>>>>>> Sorry, i forgot but is this reproducible with a recent stable 6.12.x kernel?
>>>>> Just reproduced with pristine 6.12.28.
>>>>>
>>>> okay, i've update the firmware on my older Raspberry Pi 4 to the same
>>>> version as yours. But even with your configuration i don't see this kind
>>>> of fallout. So I think we shouldn't apply this patch until we really
>>>> know what's going on.
>>> Ok, thank you, did you make sure a powered hdmi sink were connected? I
>>> noticed there is no timeout if no hdmi is plugged (but there were when
>>> monitor were powered off, maybe specific to my monitor).
>> Yes, HDMI monitor was connected to HDMI 0 and powered on. Raspberry Pi
>> OS started as expected.
>>
>> The fact that your SDIO interface triggers a warning, which I also don't
>> get let me think this is not just related to HDMI interface.
>>
>> [    3.603736] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
>> [    3.603739] mmc0: sdhci: Sys addr:  0x00000000 | Version: 0x00009902
>> [    3.646852] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt: 0x00000000
>> [    3.646856] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
>> [    3.646859] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x00000000
>> [    3.665697] mmc0: sdhci: Power:     0x0000000f | Blk gap: 0x00000000
>> [    3.672214] mmc0: sdhci: Wake-up:   0x00000000 | Clock: 0x00003947
>> [    3.678736] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
>> [    3.685254] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
>> [    3.685257] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
>> [    3.685260] mmc0: sdhci: Caps:      0x00000000 | Caps_1: 0x00000000
>> [    3.712672] mmc0: sdhci: Cmd:       0x00000000 | Max curr: 0x00000001
>> [    3.719186] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]: 0x00000000
>> [    3.725708] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]: 0x00000000
>> [    3.732230] mmc0: sdhci: Host ctl2: 0x00000000
>> [    3.736724] mmc0: sdhci: ============================================
>> [    3.819205] mmc0: new high speed SDIO card at address 0001
> Hi Stefan
>
> I think this warning is because there is nothing in SD slot (i boot from
> usb).
Okay, this was the reason why i wasn't able to reproduce. I usually boot 
from SD card.

After connecting my USB SD card reader to a USB 3.0 port (not USB 2.0 
port), I'm able to reproduce the firmware "timeout".

@Phil Do you have a explanation why USB 3.0 Boot on Raspberry Pi 4 could 
cause such a delayed reponse (> 1 s) for Firmware transaction 0x00030066?

@Etienne Actually an empty SD card shouldn't trigger such a register 
dump, but that's a different issue.