[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