test/py GPIO failure in u-boot/master

Stephen Warren swarren at wwwdotorg.org
Wed Jul 8 22:24:27 CEST 2020


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?


More information about the U-Boot mailing list