test/py GPIO failure in u-boot/master

[Simon Glass]

Hi,

On Wed, 8 Jul 2020 at 14:24, Stephen Warren <swarren at wwwdotorg.org> wrote:
>
> On 7/8/20 10:06 AM, Tom Rini wrote:
> > On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
> >> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
> >>
> >>> => ut dm gpio
> >>> Test: dm_test_gpio: gpio.c
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
> >>> Test: dm_test_gpio: gpio.c (flat tree)
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
> >>> Failures: 2
> >>
> >>
> >>> => ut dm gpio_leak
> >>> Test: dm_test_gpio_leak: gpio.c
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302, dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
> >>> Test: dm_test_gpio_leak: gpio.c (flat tree)
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137, dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, & offset, & gpio): Expected 0x0 (0), got 0xffffffea (-22)
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302, dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
> >>> Failures: 4
> >>
> >> This was introduced by one of the following changes; I'd assume due to
> >> the GPIO patch:
> >>
> >>> cmd: part: Add subcommand to list supported partition tables (detail)
> >>> cmd: fs: Add command to list supported fs types (detail)
> >>> cmd: dm: Fixed/Added DM driver listing subcommands (detail)
> >>> cmd: blkls: Add blkls command (detail)
> >>> image: Add support for ZSTD decompression (detail)
> >>> Actions: OWL: Calculate SDRAM size (detail)
> >>> arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs (detail)
> >>> clk: actions: Add Ethernet clocks (detail)
> >>> net: phy: realtek: Add support for RTL8201F PHY module. (detail)
> >>> net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust (detail)
> >>> net: designware: s700: Add glue code for S700 mac (detail)
> >>> arm: dts: s700: add node for ethernet controller (detail)
> >>> owl: Kconfig: Enable DM eth for OWL platform (detail)
> >>> configs: Enable mac and phy configs (detail)
> >>> gpio: search for gpio label if gpio is not found through bank name (detail)
> >>> test_sleep.py: make sleep time and margin configurable (detail)
> >>> fs: fat_write: fix short name creation. (detail)
> >>> trace: clang compatible handling of gd register (detail)
> >>> arm: remove outdated comment concerning -ffixed-x18 (detail)
> >>> arm: use correct argument size of special registers (detail)
> >>> arm: vexpress64: Fix counter frequency (detail)
> >>> net: dm: Remove warning about EEPROM provided MAC address (detail)
> >>> net: smc911x: Properly handle EEPROM MAC address (detail)
> >>> arm: juno: Enable DM_ETH (detail)
> >>> sata_sil: Enable DM_PCI operation (detail)
> >>> arm: juno: Enable PCI (detail)
> >>> arm: juno: Enable SATA controller (detail)
> >>
> >> I see what was probably an attempt to fix this:
> >>
> >>> commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
> >>> Author: Heiko Schocher <hs at denx.de>
> >>> Date:   Wed Jul 8 10:24:00 2020 +0200
> >>>
> >>>     gpio: fix test.py for gpio label lookup
> >>
> >> ... but the tests are still failing after that. Did that patch edit the
> >> wrong defconfig, or is there an incremental build issue that prevented
> >> that patch being effective?
> >
> > The tests are passing here and in GitLab again, so I'm not sure what's
> > happening on your end.
>
> Hmm. There is some kind of incremental build issue. I repro'd on a
> different system with a different OS, so it's not isolated to the system
> that I use to run Jenkins:
>
> # Ensure clean build
> git clean -fdx
>
> # Check out the last commit before the fix
> git checkout 526fe06a5d1d96ce22cca743576945016ec4e2ef
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests fail here due to the original GPIO issue
>
> # Check out the fix for the GPIO issue
> git checkout 7012865e961ca2645d783adf4b75ca4abdbfe5a7
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests still fail!
>
> # Ensure clean build
> rm -rf build-sandbox/
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests now pass due to clean build
>
> Masahiro, do you have any ideas?

Sadly I have seen similar issues. For example if I disable a CONFIG
and 'make' (even make xxx_defconfig; make) I now find that it doesn't
build. I would expect changing a CONFIG to cause all C files to be
rebuilt, unless we have a way to know what CONFIGs are used where?

I am not sure when this started happening, but not too long ago. I
changed buildman to do incremental builds by default and ended up
adding a -m option to clear things out.

Regards,
Simon