[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 12:13:46 CET 2018
> Am 16.12.2018 um 10:55 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
>
>> 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).
I have cross-checked: with reverting the offending patch I can
boot this board with letux-4.20-rc6.
Next idea to check: is the polarity definition of the CD gpio
ignored or wrong for the new code?
BR,
NIkolaus
More information about the Letux-kernel
mailing list