[Letux-kernel] Strange problem with non-LPAE letux-4.20-rc kernels on 4GB Pyra only

[H. Nikolaus Schaller]

Hi,
back to this problem...

> Am 05.12.2018 um 07:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 05.12.2018 um 07:18 schrieb Andreas Kemnade <andreas at kemnade.info>:
>> 
>> Hi Nikolaus,
>> 
>> On Tue, 4 Dec 2018 23:00:13 +0100
>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> 
>> [...]
>>>> root at letux:~# uname -a
>>>> Linux letux 4.20.0-rc4-letux+ #3 SMP PREEMPT Fri Nov 30 20:38:05 CET 2018 armv7l GNU/Linux
>>>> root at letux:~# 
>>>> 
>>>> panel enable is called here (my tree).  
>>> 
>>> Did you remove anything? I had tried with and without TILER patches and not seen a difference.
>>> 
>> Did you try my git branch? 
>> https://github.com/akemnade/linux
>> pyra-display-4.20-rc4
> 
> I'll try next.

Did not make a difference.

> 
>> 
>> I did not want upload anything on the goldelico server which
>> is not a clean feature branch.
>> [...]
>>> 
>>> This kernel binary was compiled Thu Nov 22 05:25:33
>>> 
>>> So something is broken in the mmc subsystem and sometimes works and
>>> sometimes doesn't Most likely depending on the month number reported
>>> by RTC.
>>> 
>> 
>> I am missing lines like that. So really a mmc problem.
>> 
>> [    3.050931] mmc3: new high speed SDHC card at address 59b4
>> [    3.057501] mmcblk3: mmc3:59b4 USD   7.51 GiB 
>> [    3.063538]  mmcblk3: p1 p2
> 
> Indeed.
> 
>> 
>> What happens if you compile the mmc host driver as a module
>> and load it manually (or unbind/rebind the driver)?
>> Just to check whether something just needs more
>> time. I would then expect that to fail at all times.
> 
> Sure. Kernel can't boot from MMC without driver built into the kernel.
> But that does not provide new information why it sometimes works
> and was working 100% before...
> 
> Maybe a git bisect between 4.19 and 4.20-rc1 is better?
> But I hesitate to start this adventure, since it is always
> time-consuming and difficult to really do since we have to add
> some feature branches to get a bootable system.
> 
> And the strange thing: I don't know what could have changed
> now and before. The only things I have done was some testing
> with different kernels and USB3-OTG.
> 
> What I can try next is to try 4.18 and older kernels until
> I have one that works in all situations.
> 
> And I could try a different SD card. with the same images.

Didn't work either.

But I just have found a way to boot the 4GB Pyra:

* remove µSD from main SD slot
* place into µSD slot
* press left top shoulder button (this forces boot from µSD by hardware)
* power on

This boots exactly the same SD Card which failed before in the big SD slot
with the PARTUUID error.

And - somehow expectedly - inserting another card (using a different µSD-SD
adapter) into the main SD slot is not recognised by the kernel...

So there is something broken with card-detection.

Ah, this might even be some hardware issue? Or pinmux related?

AFAIR U-Boot ignores the card detect input and therefore
can load the kernel and DTB from this card.

Although this all does not explain why 4.19.3 does *not*
boot from eMMC on the 2GB-Pyra with the same symptom.

Or was there a bug until a while ago that SD cards were even
detected with broken CD input? And this was fixed?

Or is this some side-effect of our SDIO-interrupt improvements
for WiFi?

What is also a little confusing is the use of ti,non-removable;
and non-removable; broken-cd; etc. in DTS.

BR,
Nikolaus