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

H. Nikolaus Schaller hns at goldelico.com
Sun Dec 16 10:55:44 CET 2018 

> Am 16.12.2018 um 09:08 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 15.12.2018 um 12:04 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Ok... well Nok...
>> 
>>> Am 14.12.2018 um 21:19 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>>> 
>>>> Hm. Shouldn't git bisect go down into the merge and look for the real patch there?
>>> 
>>> Some idea could to try CONFIG_USB=n in letux-4.20-rc1 since we do not need it to boot
>>> from MMC. If it then works, we can prove that the USB subsystem has a side-effect.
>> 
>> It seems to be a false positive by git bisect (or I have wrongly reported "good" and "bad").
>> 
>> Using CONFIG_USB=n doesn't help.
>> checkout 9703fc8caf36ac65dca1538b23dd137de0b53233 && apply patches && compile && install && boot => PARTUUID not found
>> checkout 9703fc8caf36ac65dca1538b23dd137de0b53233^ && apply patches && compile && install && boot => PARTUUID not found
>> 
>> So I should define 4.19.0 as good and 9703fc8caf36ac65dca1538b23dd137de0b53233^ as bad and start another round of bisect...
> 
> For summary again:
> 
> bad case: kernel stops with
> 
> [    3.473657] sr_init: No PMIC hook to init smartreflex
> [    3.479880] vmmcsdio_fixed: disabling
> [    3.484345] ldo3: disabling
> [    3.487981] ldo8: disabling
> [    3.498640] ALSA device list:
> [    3.501745]   No soundcards found.
> [    3.505668] Waiting for root device PARTUUID=c8a507cd-02...
> 
> although U-Boot and external SD card reader confirms that the PARTUUID is c8a507cd-02
> 
> good case:
> 
> [    3.526955] sr_init: No PMIC hook to init smartreflex
> [    3.533200] vmmcsdio_fixed: disabling
> [    3.537948] ldo3: disabling
> [    3.541893] ldo8: disabling
> [    3.552425] ALSA device list:
> [    3.555526]   No soundcards found.
> [    3.584375] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
> [    3.593118] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [    3.609188] devtmpfs: mounted
> [    3.612978] Freeing unused kernel memory: 1024K
> [    3.617863] Run /sbin/init as init process
> 
> Running git bisect again (I probably did mark some commit wrongly as good/bad)
> has now revealed patch:
> 
> e63201f19438372fcb45977d8e14c6ab5807d55b is the first bad commit
> commit e63201f19438372fcb45977d8e14c6ab5807d55b
> Author: Linus Walleij <linus.walleij at linaro.org>
> Date:   Mon Sep 24 13:30:51 2018 +0200
> 
>    mmc: omap_hsmmc: Delete platform data GPIO CD and WP
> 
>    The OMAP HSMMC driver has some elaborate and hairy handling for
>    passing GPIO card detect and write protect lines from a boardfile
>    into the driver: the machine defines a struct omap2_hsmmc_info
>    that is copied into struct omap_hsmmc_platform_data by
>    omap_hsmmc_pdata_init() in arch/arm/mach-omap2/hsmmc.c.
> 
>    However the .gpio_cd and .gpio_wp fields are not copied from
>    omap2_hsmmc_info to omap_hsmmc_platform_data by
>    omap_hsmmc_pdata_init() so they remain unused. The only platform
>    defining omap2_hsmmc_info also define both to -1, unused.
> 
>    It turn out there are no boardfiles passing any valid GPIO
>    lines into the OMAP HSMMC driver at all. And since we are not
>    going to add any more OMAP2 boardfiles, we can delete this
>    card detect and write protect handling altogether.
> 
>    This seems to also fix a bug: the card detect callback
>    mmc_gpio_get_cd() in the slot GPIO core needs to be called
>    by drivers utilizing slot GPIO. It appears the the boardfile
>    quirks were not doing this right, so this would only get
>    called for boardfiles, i.e. since no boardfile was using it,
>    never.
> 
>    Just assign mmc_gpio_get_cd() unconditionally to omap_hsmmc_ops
>    .get_cd() so card detects from the device tree works.
>    AFAICT card detect with GPIO lines assigned from
>    mmc_of_parse() are not working at the moment, but that is
>    no regression since it probably never worked.
> 
> Yes, that is very reasonable to be the offending patch.
> 
> And the last sentence is probably the problem!!!
> It contains a lot of speculation and assumption that it does
> not break anything... I am quite sure that a patch submitted by me
> with this description would have been rejected...
> 
> I am tempted to propose a simple revert just because it *is* a
> regression for us using a proper (at least I think so) DTS...
> 
> But it is still not clear why it works on GTA04 and the older
> Pyra prototype. And why it works with the other SD slot.
> 
> Maybe they have removed some special side-effect of omap_hsmmc_gpio_init()?
> Or this board has a broken gpio (returning always "1") which was ignored
> before this patch because we have no board file?

Ok, the gpio seems to work - at least mostly (there is a proper pull-up missing).

root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6fcf000.
Value at address 0x48053138 (0xb6fcf138): 0x30

^^^ these are gpio8_228 (CD) and gpio_229 (WP)

root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f7d000.
Value at address 0x48053138 (0xb6f7d138): 0x30
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f1e000.
Value at address 0x48053138 (0xb6f1e138): 0x30
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f42000.
Value at address 0x48053138 (0xb6f42138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f02000.
Value at address 0x48053138 (0xb6f02138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6fd0000.
Value at address 0x48053138 (0xb6fd0138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6fc1000.
Value at address 0x48053138 (0xb6fc1138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6fab000.
Value at address 0x48053138 (0xb6fab138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f71000.
Value at address 0x48053138 (0xb6f71138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f88000.
Value at address 0x48053138 (0xb6f88138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f41000.
Value at address 0x48053138 (0xb6f41138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f79000.
Value at address 0x48053138 (0xb6f79138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f62000.
Value at address 0x48053138 (0xb6f62138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f0a000.
Value at address 0x48053138 (0xb6f0a138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6fcf000.
Value at address 0x48053138 (0xb6fcf138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f5e000.
Value at address 0x48053138 (0xb6f5e138): 0x20
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f59000.
Value at address 0x48053138 (0xb6f59138): 0x10
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138[  779.557025] mmc3: card never left busy state
[  779.561728] mmc3: error -110 whilst initialising SD card

^^^ strange error when taking out the SD card.
vvv then I activated the lock switch (WP):

/dev/mem opened.
Memory mapped at address 0xb6f2d000.
Value at address 0x48053138 (0xb6f2d138): 0x0
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6ffa000.
Value at address 0x48053138 (0xb6ffa138): 0x0
root at letux:~# /usr/bin/arm-linux-gnueabihf/devmem2 0x48053138
/dev/mem opened.
Memory mapped at address 0xb6f3b000.
Value at address 0x48053138 (0xb6f3b138): 0x10
root at letux:~#

So this means WP and CD are (basically) working (besides the
known problem of missing pull-up which should be almost harmless
if the card is inserted - it may only write-protect the card
unexpectedly).

BR,
Nikolaus

More information about the Letux-kernel mailing list