[PATCH 00/11] Fixes for Nokia RX-51

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

This patch series contain fixes for Nokia RX-51 board (aka N900).
After these changes it is possible to run U-Boot in qemu emulator again.
And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
problem.

Pali Roh?r (11):
  Nokia RX-51: Update my email address
  Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
  Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
  Nokia RX-51: Move code from defconfig back to C header file
  Nokia RX-51: Revert back onenand defitions
  Nokia RX-51: Remove PART* macros
  Nokia RX-51: Remember setup_console_atag option
  Nokia RX-51: Enable CONFIG_CONSOLE_MUX
  Nokia RX-51: Disable some unused features to decrease size of u-boot
    binary
  Nokia RX-51: Update README.nokia_rx51
  Nokia RX-51: Add automated test for running RX-51 build in qemu

 .travis.yml                      |  10 ++
 board/nokia/rx51/MAINTAINERS     |   3 +-
 board/nokia/rx51/lowlevel_init.S |  11 +-
 board/nokia/rx51/rx51.c          |  43 ++++---
 board/nokia/rx51/rx51.h          |   2 +-
 board/nokia/rx51/tag_omap.h      |   4 +-
 cmd/bootmenu.c                   |   2 +-
 configs/nokia_rx51_defconfig     |  27 +++-
 doc/README.bootmenu              |   2 +-
 doc/README.nokia_rx51            |  32 +++--
 include/ansi.h                   |   2 +-
 include/configs/nokia_rx51.h     |  88 ++++---------
 test/rx51_test.sh                | 208 +++++++++++++++++++++++++++++++
 13 files changed, 327 insertions(+), 107 deletions(-)
 create mode 100755 test/rx51_test.sh

-- 
2.20.1

[PATCH 01/11] Nokia RX-51: Update my email address

[Pali Rohár]

I'm using a new email address, so reflect this state also in U-Boot.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 board/nokia/rx51/MAINTAINERS     | 2 +-
 board/nokia/rx51/lowlevel_init.S | 2 +-
 board/nokia/rx51/rx51.c          | 2 +-
 board/nokia/rx51/rx51.h          | 2 +-
 board/nokia/rx51/tag_omap.h      | 4 ++--
 cmd/bootmenu.c                   | 2 +-
 doc/README.bootmenu              | 2 +-
 include/ansi.h                   | 2 +-
 include/configs/nokia_rx51.h     | 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index 8bdddc1d83..4cf3dcce2e 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -1,5 +1,5 @@
 RX51 BOARD
-M:	Pali Roh?r <pali.rohar@gmail.com>
+M:	Pali Roh?r <pali@kernel.org>
 S:	Maintained
 F:	board/nokia/rx51/
 F:	include/configs/nokia_rx51.h
diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S
index 6871a5a74f..7b1e50d9bc 100644
--- a/board/nokia/rx51/lowlevel_init.S
+++ b/board/nokia/rx51/lowlevel_init.S
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * (C) Copyright 2011-2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  */
 
 #include <config.h>
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 71ca79deab..80a0fc2696 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -4,7 +4,7 @@
  * ?????? ???????? <freemangordon@abv.bg>
  *
  * (C) Copyright 2011-2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  *
  * (C) Copyright 2010
  * Alistair Buxton <a.j.buxton@gmail.com>
diff --git a/board/nokia/rx51/rx51.h b/board/nokia/rx51/rx51.h
index fc336ee819..fa1b42bf21 100644
--- a/board/nokia/rx51/rx51.h
+++ b/board/nokia/rx51/rx51.h
@@ -4,7 +4,7 @@
  * ?????? ???????? <freemangordon@abv.bg>
  *
  * (C) Copyright 2011-2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  *
  * (C) Copyright 2008
  * Dirk Behme <dirk.behme@gmail.com>
diff --git a/board/nokia/rx51/tag_omap.h b/board/nokia/rx51/tag_omap.h
index c445aafde0..b99d6b7de1 100644
--- a/board/nokia/rx51/tag_omap.h
+++ b/board/nokia/rx51/tag_omap.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * (C) Copyright 2011-2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  *
  * (C) Copyright 2011
  * marcel at mesa.nl, Mesa Consulting B.V.
@@ -182,7 +182,7 @@ struct omap_em_asic_bb5_config {
  *  processing omap tag structures
  *
  *  Copyright (C) 2011  marcel at mesa.nl, Mesa Consulting B.V.
- *  Copyright (C) 2012  Pali Roh?r <pali.rohar@gmail.com>
+ *  Copyright (C) 2012  Pali Roh?r <pali@kernel.org>
  */
 
 /* TI OMAP specific information */
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 3dc2c854ac..2f20bb88f3 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * (C) Copyright 2011-2013 Pali Roh?r <pali.rohar@gmail.com>
+ * (C) Copyright 2011-2013 Pali Roh?r <pali@kernel.org>
  */
 
 #include <common.h>
diff --git a/doc/README.bootmenu b/doc/README.bootmenu
index ca5099089e..9ff89f2e55 100644
--- a/doc/README.bootmenu
+++ b/doc/README.bootmenu
@@ -1,6 +1,6 @@
 SPDX-License-Identifier: GPL-2.0+
 /*
- * (C) Copyright 2011-2012 Pali Roh?r <pali.rohar@gmail.com>
+ * (C) Copyright 2011-2012 Pali Roh?r <pali@kernel.org>
  */
 
 ANSI terminal bootmenu command
diff --git a/include/ansi.h b/include/ansi.h
index e90a697eaf..af1a3712c8 100644
--- a/include/ansi.h
+++ b/include/ansi.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * (C) Copyright 2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  */
 
 /*
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index fd755bbcea..d2cafb0a8b 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * (C) Copyright 2011-2012
- * Pali Roh?r <pali.rohar@gmail.com>
+ * Pali Roh?r <pali@kernel.org>
  *
  * (C) Copyright 2010
  * Alistair Buxton <a.j.buxton@gmail.com>
-- 
2.20.1

[PATCH 02/11] Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS

[Pali Rohár]

This entry was missing in MAINTAINERS file.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 board/nokia/rx51/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index 4cf3dcce2e..f2a712620b 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -4,3 +4,4 @@ S:	Maintained
 F:	board/nokia/rx51/
 F:	include/configs/nokia_rx51.h
 F:	configs/nokia_rx51_defconfig
+F:	doc/README.nokia_rx51
-- 
2.20.1

[PATCH 03/11] Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place

[Pali Rohár]

In commit commit 278b90ce786f ("configs: Migrate CONFIG_SYS_TEXT_BASE") was
moved definition for CONFIG_SYS_TEXT_BASE option but author probably forgot
to move also comment for lines which are moving. So do it now!

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 board/nokia/rx51/lowlevel_init.S | 9 ++++++++-
 include/configs/nokia_rx51.h     | 6 ------
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S
index 7b1e50d9bc..1466d976fc 100644
--- a/board/nokia/rx51/lowlevel_init.S
+++ b/board/nokia/rx51/lowlevel_init.S
@@ -155,7 +155,14 @@ copy_code_end:
 	mov	pc, r2
 
 
-/* Copy u-boot to address CONFIG_SYS_TEXT_BASE */
+/*
+ * Copy u-boot to address CONFIG_SYS_TEXT_BASE
+ *
+ * Nokia X-Loader loading secondary image to address 0x80400000
+ * NOLO loading boot image to random place, so it doesn't really
+ * matter what is set in CONFIG_SYS_TEXT_BASE. We have to copy
+ * u-boot to CONFIG_SYS_TEXT_BASE address.
+ */
 
 copy_uboot_start:
 	/* r0 - start of u-boot before */
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index d2cafb0a8b..858951ccf2 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -25,12 +25,6 @@
 
 #define CONFIG_MACH_TYPE		MACH_TYPE_NOKIA_RX51
 
-/*
- * Nokia X-Loader loading secondary image to address 0x80400000
- * NOLO loading boot image to random place, so it doesn't really
- * matter what we set this to. We have to copy u-boot to this address
- */
-
 #include <asm/arch/cpu.h>		/* get chip and board defs */
 #include <asm/arch/omap.h>
 #include <asm/arch/mem.h>
-- 
2.20.1

[PATCH 04/11] Nokia RX-51: Move code from defconfig back to C header file

[Pali Rohár]

In commit commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and
CONFIG_PREBOOT to Kconfig") was moved complicated multiline script code
from C header to oneliner in defconfig. After this change multiline to wide
oneliner it is hard to read this code and even harder to debug. Moreover
this script code should be at place where are other scripts, so move it
back to C header file.

Define new env variable preboot which stores this script and in option
CONFIG_PREBOOT calls this preboot variable.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 configs/nokia_rx51_defconfig |  2 +-
 include/configs/nokia_rx51.h | 22 ++++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index f9e5b0e123..5ba9768d02 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -6,7 +6,7 @@ CONFIG_TARGET_NOKIA_RX51=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_BOOTDELAY=30
 CONFIG_USE_PREBOOT=y
-CONFIG_PREBOOT="setenv mmcnum 1; setenv mmcpart 1;setenv mmcscriptfile bootmenu.scr;if run switchmmc; then setenv mmcdone true;setenv mmctype fat;if run scriptload; then true; else setenv mmctype ext2;if run scriptload; then true; else setenv mmctype ext4;if run scriptload; then true; else setenv mmcdone false;fi;fi;fi;if ${mmcdone}; then run scriptboot;fi;fi;if run slide; then true; else setenv bootmenu_delay 0;setenv bootdelay 0;fi"
+CONFIG_PREBOOT="run preboot"
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_HUSH_PARSER=y
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 858951ccf2..57bcbbaae1 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -239,6 +239,28 @@ int rx51_kp_getc(struct stdio_dev *sdev);
 		"fi\0" \
 	"emmcboot=setenv mmcnum 1; run trymmcboot\0" \
 	"sdboot=setenv mmcnum 0; run trymmcboot\0" \
+	"preboot=setenv mmcnum 1; setenv mmcpart 1;" \
+		"setenv mmcscriptfile bootmenu.scr;" \
+		"if run switchmmc; then " \
+			"setenv mmcdone true;" \
+			"setenv mmctype fat;" \
+			"if run scriptload; then true; else " \
+				"setenv mmctype ext2;" \
+				"if run scriptload; then true; else " \
+					"setenv mmctype ext4;" \
+					"if run scriptload; then true; else " \
+						"setenv mmcdone false;" \
+					"fi;" \
+				"fi;" \
+			"fi;" \
+			"if ${mmcdone}; then " \
+				"run scriptboot;" \
+			"fi;" \
+		"fi;" \
+		"if run slide; then true; else " \
+			"setenv bootmenu_delay 0;" \
+			"setenv bootdelay 0;" \
+		"fi\0" \
 	"menucmd=bootmenu\0" \
 	"bootmenu_0=Attached kernel=run attachboot\0" \
 	"bootmenu_1=Internal eMMC=run emmcboot\0" \
-- 
2.20.1

[PATCH 05/11] Nokia RX-51: Revert back onenand defitions

[Pali Rohár]

In commit commit 43ede0bca7fc ("Kconfig: Migrate MTDIDS_DEFAULT /
MTDPARTS_DEFAULT") were removed definitions for onenand partitions.

Revert them back and enable needed options for onenand support.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 configs/nokia_rx51_defconfig |  7 +++++++
 include/configs/nokia_rx51.h | 10 ----------
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 5ba9768d02..13bb6d07b7 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -39,3 +39,10 @@ CONFIG_TWL4030_USB=y
 CONFIG_VIDEO=y
 CONFIG_CFB_CONSOLE_ANSI=y
 # CONFIG_VGA_AS_SINGLE_DEVICE is not set
+CONFIG_MTD=y
+CONFIG_MTDIDS_DEFAULT="onenand0=onenand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=onenand:128k(bootloader)ro,384k(config),256k(log),2m(kernel),2m(initfs),-(rootfs)"
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_RAW_NAND is not set
+CONFIG_CMD_MTD=y
+CONFIG_CMD_ONENAND=y
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 57bcbbaae1..cfc4d0c1e5 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -133,12 +133,8 @@
 #define PART6_OFFS			0x004c0000
 #define PART6_MASK			0x00000000
 
-#ifdef ONENAND_SUPPORT
-
 #define CONFIG_SYS_ONENAND_BASE		ONENAND_MAP
 
-#endif
-
 /* Watchdog support */
 #define CONFIG_HW_WATCHDOG
 
@@ -163,13 +159,7 @@ int rx51_kp_getc(struct stdio_dev *sdev);
 #endif
 
 /* Environment information */
-#ifdef CONFIG_MTDPARTS_DEFAULT
-#define MTDPARTS "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
-#else
-#define MTDPARTS
-#endif
 #define CONFIG_EXTRA_ENV_SETTINGS \
-	MTDPARTS \
 	"usbtty=cdc_acm\0" \
 	"stdin=vga\0" \
 	"stdout=vga\0" \
-- 
2.20.1

[PATCH 06/11] Nokia RX-51: Remove PART* macros

[Pali Rohár]

Now when code for defining partitions is duplicated at two locations
(option CONFIG_MTDPARTS_DEFAULT in nokia_rx51_defconfig file and macro
OMAP_TAG_PARTITION_CONFIG in rx51.c file) there is no need to have common
macros. Lets inline PART* macros to rx51.c file.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 board/nokia/rx51/rx51.c      | 18 ++++++----------
 include/configs/nokia_rx51.h | 42 ------------------------------------
 2 files changed, 6 insertions(+), 54 deletions(-)

diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 80a0fc2696..c8ef26f940 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -69,18 +69,12 @@ static struct tag_omap omap[] = {
 	OMAP_TAG_GPIO_SWITCH_CONFIG("sleep_ind", 0xa2, 0x2, 0x2, 0x0),
 	OMAP_TAG_GPIO_SWITCH_CONFIG("slide", GPIO_SLIDE, 0x0, 0x0, 0x0),
 	OMAP_TAG_WLAN_CX3110X_CONFIG(0x25, 0xff, 87, 42, -1),
-	OMAP_TAG_PARTITION_CONFIG(PART1_NAME, PART1_SIZE * PART1_MULL,
-			PART1_OFFS, PART1_MASK),
-	OMAP_TAG_PARTITION_CONFIG(PART2_NAME, PART2_SIZE * PART2_MULL,
-			PART2_OFFS, PART2_MASK),
-	OMAP_TAG_PARTITION_CONFIG(PART3_NAME, PART3_SIZE * PART3_MULL,
-			PART3_OFFS, PART3_MASK),
-	OMAP_TAG_PARTITION_CONFIG(PART4_NAME, PART4_SIZE * PART4_MULL,
-			PART4_OFFS, PART4_MASK),
-	OMAP_TAG_PARTITION_CONFIG(PART5_NAME, PART5_SIZE * PART5_MULL,
-			PART5_OFFS, PART5_MASK),
-	OMAP_TAG_PARTITION_CONFIG(PART6_NAME, PART6_SIZE * PART6_MULL,
-			PART6_OFFS, PART6_MASK),
+	OMAP_TAG_PARTITION_CONFIG("bootloader", 128 * 1024, 0x00000000, 0x00000003),
+	OMAP_TAG_PARTITION_CONFIG("config", 384 * 1024, 0x00020000, 0x00000000),
+	OMAP_TAG_PARTITION_CONFIG("log", 256 * 1024, 0x00080000, 0x00000000),
+	OMAP_TAG_PARTITION_CONFIG("kernel", 2 * 1024*1024, 0x000c0000, 0x00000000),
+	OMAP_TAG_PARTITION_CONFIG("initfs", 2 * 1024*1024, 0x002c0000, 0x00000000),
+	OMAP_TAG_PARTITION_CONFIG("rootfs", 257280 * 1024, 0x004c0000, 0x00000000),
 	OMAP_TAG_BOOT_REASON_CONFIG("pwr_key"),
 	OMAP_TAG_VERSION_STR_CONFIG("product", "RX-51"),
 	OMAP_TAG_VERSION_STR_CONFIG("hw-build", "2101"),
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index cfc4d0c1e5..a33b0a7ac8 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -91,48 +91,6 @@
  * Board ONENAND Info.
  */
 
-#define PART1_NAME			"bootloader"
-#define PART1_SIZE			128
-#define PART1_MULL			1024
-#define PART1_SUFF			"k"
-#define PART1_OFFS			0x00000000
-#define PART1_MASK			0x00000003
-
-#define PART2_NAME			"config"
-#define PART2_SIZE			384
-#define PART2_MULL			1024
-#define PART2_SUFF			"k"
-#define PART2_OFFS			0x00020000
-#define PART2_MASK			0x00000000
-
-#define PART3_NAME			"log"
-#define PART3_SIZE			256
-#define PART3_MULL			1024
-#define PART3_SUFF			"k"
-#define PART3_OFFS			0x00080000
-#define PART3_MASK			0x00000000
-
-#define PART4_NAME			"kernel"
-#define PART4_SIZE			2
-#define PART4_MULL			1024*1024
-#define PART4_SUFF			"m"
-#define PART4_OFFS			0x000c0000
-#define PART4_MASK			0x00000000
-
-#define PART5_NAME			"initfs"
-#define PART5_SIZE			2
-#define PART5_MULL			1024*1024
-#define PART5_SUFF			"m"
-#define PART5_OFFS			0x002c0000
-#define PART5_MASK			0x00000000
-
-#define PART6_NAME			"rootfs"
-#define PART6_SIZE			257280
-#define PART6_MULL			1024
-#define PART6_SUFF			"k"
-#define PART6_OFFS			0x004c0000
-#define PART6_MASK			0x00000000
-
 #define CONFIG_SYS_ONENAND_BASE		ONENAND_MAP
 
 /* Watchdog support */
-- 
2.20.1

[PATCH 07/11] Nokia RX-51: Remember setup_console_atag option

[Pali Rohár]

When variable setup_console_atag is unset then read default value from OMAP
atags which passed NOLO bootloader to U-Boot.

This would allow to boot Maemo Linux kernel from U-Boot with serial console
settings configured in NOLO bootloader (which loads U-Boot).

So serial console needs to be enabled only at one place, globally in NOLO.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 board/nokia/rx51/rx51.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index c8ef26f940..a282fe68a6 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -87,6 +87,7 @@ static char *boot_reason_ptr;
 static char *hw_build_ptr;
 static char *nolo_version_ptr;
 static char *boot_mode_ptr;
+static int serial_was_console_enabled;
 
 /*
  * Routine: init_omap_tags
@@ -143,6 +144,13 @@ static void reuse_omap_atags(struct tag_omap *t)
 				strcpy(boot_mode_ptr, version);
 			}
 			break;
+		case OMAP_TAG_UART:
+			if (!t->u.uart.enabled_uarts)
+				serial_was_console_enabled = 1;
+			break;
+		case OMAP_TAG_SERIAL_CONSOLE:
+			serial_was_console_enabled = 1;
+			break;
 		default:
 			break;
 		}
@@ -233,10 +241,17 @@ void setup_board_tags(struct tag **in_params)
 		return;
 
 	str = env_get("setup_console_atag");
-	if (str && str[0] == '1')
-		setup_console_atag = 1;
-	else
-		setup_console_atag = 0;
+	if (str && str[0]) {
+		if (str[0] == '1')
+			setup_console_atag = 1;
+		else
+			setup_console_atag = 0;
+	} else {
+		if (serial_was_console_enabled)
+			setup_console_atag = 1;
+		else
+			setup_console_atag = 0;
+	}
 
 	setup_boot_reason_atag = env_get("setup_boot_reason_atag");
 	setup_boot_mode_atag = env_get("setup_boot_mode_atag");
-- 
2.20.1

[PATCH 08/11] Nokia RX-51: Enable CONFIG_CONSOLE_MUX

[Pali Rohár]

After this change both device display and serial console would contain
U-Boto output automatically without any future configuration. This would
allow easier debugging on real device as access to serial console is hard
and also in qemu emulator where it is easier to copy+paste from serial
console as from SDL framebuffer.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 configs/nokia_rx51_defconfig | 2 +-
 include/configs/nokia_rx51.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 13bb6d07b7..fc92c3affc 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -7,7 +7,7 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_BOOTDELAY=30
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="run preboot"
-# CONFIG_CONSOLE_MUX is not set
+CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Nokia RX-51 # "
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index a33b0a7ac8..4014dca54c 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -119,9 +119,9 @@ int rx51_kp_getc(struct stdio_dev *sdev);
 /* Environment information */
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	"usbtty=cdc_acm\0" \
-	"stdin=vga\0" \
-	"stdout=vga\0" \
-	"stderr=vga\0" \
+	"stdin=serial,vga\0" \
+	"stdout=serial,vga\0" \
+	"stderr=serial,vga\0" \
 	"setcon=setenv stdin ${con};" \
 		"setenv stdout ${con};" \
 		"setenv stderr ${con}\0" \
-- 
2.20.1

[PATCH 08/11] Nokia RX-51: Enable CONFIG_CONSOLE_MUX

[Lokesh Vutla]

On 01/04/20 4:05 AM, Pali Roh?r wrote:
> After this change both device display and serial console would contain
> U-Boto output automatically without any future configuration. This would

s/U-Boto/U-Boot

with that,
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[PATCH 09/11] Nokia RX-51: Disable some unused features to decrease size of u-boot binary

[Pali Rohár]

Maximal allowed size of U-Boot binary for Nokia N900 is just 262144 bytes.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 configs/nokia_rx51_defconfig | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index fc92c3affc..41722725e6 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -26,6 +26,7 @@ CONFIG_CMD_FAT=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 # CONFIG_NET is not set
 CONFIG_TWL4030_LED=y
+# CONFIG_MMC_HW_PARTITIONING is not set
 CONFIG_MMC_OMAP_HS=y
 CONFIG_CONS_INDEX=3
 CONFIG_SYS_NS16550=y
@@ -46,3 +47,18 @@ CONFIG_MTD_PARTITIONS=y
 # CONFIG_MTD_RAW_NAND is not set
 CONFIG_CMD_MTD=y
 CONFIG_CMD_ONENAND=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_GZIP is not set
+# CONFIG_FIT is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+# CONFIG_CMD_FLASH is not set
-- 
2.20.1

[PATCH 10/11] Nokia RX-51: Update README.nokia_rx51

[Pali Rohár]

Fix some typos, add information about setup_omap_atag, remove old suff
about ONENAND_SUPPORT and update guide for UBIFS.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 doc/README.nokia_rx51 | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 586ed7c1cc..33c275b416 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -19,7 +19,7 @@ stored ATAGs (see boot order).
 There is support for hardware watchdog. Hardware watchdog is started by
 NOLO so u-boot must kick watchdog to prevent reboot device (but not very
 often, max every 2 seconds). There is also support for framebuffer display
-output with ANSI espace codes and the N900 HW keyboard input. USB tty works
+output with ANSI escape codes and the N900 HW keyboard input. USB tty works
 but is disabled because it prevents the current Maemo kernel from booting.
 
 When U-Boot is starting it enable IBE bit in Auxiliary Control Register,
@@ -36,7 +36,7 @@ Boot from SD or eMMC in this order:
 
  * 1.
    * 1.1 find boot.scr on first fat partition
-   * 1.2 find uImage on first fat parition
+   * 1.2 find uImage on first fat partition
    * 1.3 same order for 2. - 4. fat partition
  * 2. same as 1. but for ext2/3 partition
  * 3. same as 1. but for ext4 partition
@@ -62,21 +62,26 @@ Available additional commands/variables:
  * run trymmcscriptboot - Try to load and boot script ${mmcscriptfile}
  * run trymmckernboot - Try to load and boot kernel image ${mmckernfile}
  * run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile}
-			      with initrd image ${mmcinitrdfile}
+                              with initrd image ${mmcinitrdfile}
 
 Additional variables for loading files from mmc:
 
  * mmc ${mmcnum} (0 - external, 1 - internal)
  * partition number ${mmcpart} (1 - 4)
- * parition type ${mmctype} (fat, ext2)
+ * parition type ${mmctype} (fat, ext2, ext4)
 
-Additional varuables for booting kernel:
+Additional variables for booting kernel:
 
  * setup_omap_atag - Add OMAP table into atags structure (needs maemo kernel)
  * setup_console_atag - Enable serial console in OMAP table
  * setup_boot_reason_atag - Change boot reason in OMAP table
  * setup_boot_mode_atag - Change boot mode in OMAP table
 
+ Variable setup_omap_atag is automatically set when booting attached kernel.
+ When variable setup_omap_atag is set, variable setup_console_atag is unset
+ and u-boot standard output is set to serial then setup_console_atag is
+ automatically set to 1. So output from Maemo kernel would go to serial port.
+
 USB TTY:
 
  Maemo kernel 2.6.28 will crash if u-boot enable usb tty. So USB TTY is disabled.
@@ -85,20 +90,13 @@ USB TTY:
  #define CONFIG_USB_TTY
 
 
-ONENAND support:
-
- ONENAND support is disabled because not working yet and cause linux kernel to
- crash or no access to mtd. For enabling ONENAND support add this line at begin
- of file include/configs/nokia_rx51.h
-
- #define ONENAND_SUPPORT
-
-
 UBIFS support:
 
  UBIFS support is disabled, because U-Boot image is too big and cannot be
  flashed with attached zImage to RX-51 kernel nand area. For enabling UBIFS
- support first enable ONENAND support and then add this line at begin of file
- include/configs/nokia_rx51.h
+ support add following lines into file configs/nokia_rx51_defconfig
 
- #define UBIFS_SUPPORT
+ CONFIG_CMD_UBI=y
+ CONFIG_CMD_UBIFS=y
+ CONFIG_MTD_UBI_FASTMAP=y
+ CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
-- 
2.20.1

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

This patch contains a script which automatically download and compile all
needed tools to build a simple MTD images for booting Maemo kernel image by
U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
machine provided by qemu-linaro project.

It can be used to check that U-Boot for Nokia N900 is not broken and can be
successfully booted in emulator.

Script is registered in to .travis.yml so it would be automatically run on
Travi CI service.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 .travis.yml       |  10 +++
 test/rx51_test.sh | 208 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 218 insertions(+)
 create mode 100755 test/rx51_test.sh

diff --git a/.travis.yml b/.travis.yml
index c59bd7790b..d96811473c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -40,6 +40,8 @@ addons:
     - clang-7
     - srecord
     - graphviz
+    - mtools
+    - mtd-utils
 
 install:
  # Clone uboot-test-hooks
@@ -116,6 +118,11 @@ script:
  # Comments must be outside the command strings below, or the Travis parser
  # will get confused.
  #
+ # Run tests for Nokia RX-51 (aka N900)
+ - if [[ -n "${NOKIA_RX51}" ]]; then
+     test/rx51_test.sh
+     exit $?;
+   fi
  # From buildman, exit code 129 means warnings only.  If we've been asked to
  # use clang only do one configuration.
  - if [[ "${BUILDMAN}" != "" ]]; then
@@ -160,6 +167,9 @@ matrix:
   include:
   # we need to build by vendor due to 50min time limit for builds
   # each env setting here is a dedicated build
+    - name: "nokia rx51"
+      env:
+        - NOKIA_RX51=1
     - name: "buildman arc"
       env:
         - BUILDMAN="arc"
diff --git a/test/rx51_test.sh b/test/rx51_test.sh
new file mode 100755
index 0000000000..43ecc07c08
--- /dev/null
+++ b/test/rx51_test.sh
@@ -0,0 +1,208 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: GPL-2.0+
+# (C) 2020 Pali Roh?r <pali@kernel.org>
+
+# This test script depends on external tools:
+# wget git truncate tar dpkg dd mcopy (from mtools) mkfs.ubifs (from mtd-utils) ubinize (from mtd-utils)
+
+# Download and compile linaro version qemu which has support for n900 machine
+# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+if ! test -f qemu-system-arm; then
+	test -d qemu-linaro || git clone https://git.linaro.org/qemu/qemu-linaro.git
+	cd qemu-linaro
+	git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+	./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list=pa,alsa --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
+	make -j4
+	cd ..
+	ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
+fi
+
+# Download and compile dosfstools with mbr support
+# Currently this support is in open pull request 95
+if ! test -f mkfs.fat; then
+	test -d dosfstools || git clone https://github.com/dosfstools/dosfstools.git
+	cd dosfstools
+	git fetch origin refs/pull/95/head
+	git checkout FETCH_HEAD
+	./autogen.sh
+	./configure
+	make -j4
+	cd ..
+	ln -s dosfstools/src/mkfs.fat .
+fi
+
+# Download qflasher and nolo images
+# This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution
+wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
+tar -xf qemu-n900.tar.gz
+
+# Download Maemo script u-boot-gen-combined
+if ! test -f u-boot-gen-combined; then
+	test -d u-boot-maemo || git clone https://github.com/pali/u-boot-maemo.git
+	chmod +x u-boot-maemo/debian/u-boot-gen-combined
+	ln -s u-boot-maemo/debian/u-boot-gen-combined .
+fi
+
+# Download Maemo fiasco kernel
+wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
+
+# Download Maemo libc
+wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
+dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
+
+# Download Maemo busybox
+wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
+dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
+
+# Generate rootfs directory
+# WARNING: there is "sudo mknod" call for /dev/console
+mkdir -p rootfs
+mkdir -p rootfs/dev/
+mkdir -p rootfs/bin/
+mkdir -p rootfs/sbin/
+mkdir -p rootfs/lib/
+test -c rootfs/dev/console || sudo mknod rootfs/dev/console c 5 1
+cp -a busybox_1.10.2/bin/busybox rootfs/bin/
+cp -a libc6_2.5.1/lib/ld-linux.so.3 rootfs/lib/
+cp -a libc6_2.5.1/lib/ld-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libc.so.6 rootfs/lib/
+cp -a libc6_2.5.1/lib/libc-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt.so.1 rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt-2.5.so rootfs/lib/
+test -f rootfs/bin/sh || ln -sf busybox rootfs/bin/sh
+test -f rootfs/sbin/poweroff || ln -sf ../bin/busybox rootfs/sbin/poweroff
+cat > rootfs/sbin/preinit << EOF
+#!/bin/sh
+echo
+echo "Successfully booted"
+echo
+/sbin/poweroff -f
+EOF
+chmod +x rootfs/sbin/preinit
+
+# Generate bootmenu for eMMC booting
+cat > bootmenu_emmc << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from eMMC=setenv mmcnum 1; setenv mmcpart 1; setenv mmctype fat; setenv bootargs; setenv setup_omap_atag 1; setenv mmckernfile uImage-2.6.28-omap1; run trymmckernboot';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_emmc bootmenu_emmc.scr
+
+# Generate bootmenu for OneNAND booting
+# FIXME: is address, size and offset really correct?
+cat > bootmenu_nand << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from OneNAND=mtd read initfs \${kernaddr} 0x800 0x1FF800; setenv bootargs; setenv setup_omap_atag 1; bootm \${kernaddr}';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_nand bootmenu_nand.scr
+
+# Generate ubi config file for ubi rootfs image
+cat > ubi.ini << EOF
+[rootfs]
+mode=ubi
+image=ubifs.img
+vol_id=0
+vol_size=160MiB
+vol_type=dynamic
+vol_name=rootfs
+vol_alignment=1
+vol_flags=autoresize
+EOF
+
+# Generate combined image from u-boot and Maemo fiasco kernel
+dd if=kernel_2.6.28/boot/zImage-2.6.28-20103103+0m5.fiasco of=zImage-2.6.28-omap1 skip=95 bs=1
+./mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage-2.6.28-omap1 -d zImage-2.6.28-omap1 uImage-2.6.28-omap1
+./u-boot-gen-combined u-boot.bin uImage-2.6.28-omap1 combined.bin
+
+# Generate combined hack image from u-boot and Maemo fiasco kernel (kernel starts@2MB offset)
+cp u-boot.bin combined_hack.bin
+dd if=uImage-2.6.28-omap1 of=combined_hack.bin bs=1024 seek=2048
+
+# Generate ubi rootfs image from rootfs directory
+/usr/sbin/mkfs.ubifs -m 2048 -e 129024 -c 2047 -r rootfs ubifs.img
+/usr/sbin/ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi.ini
+
+# Generate FAT32 eMMC image for eMMC booting
+truncate -s 50MiB emmc_emmc.img
+./mkfs.fat --mbr -F32 emmc_emmc.img
+mcopy uImage-2.6.28-omap1 ::/uImage-2.6.28-omap1 -i emmc_emmc.img
+mcopy bootmenu_emmc.scr ::/bootmenu.scr -i emmc_emmc.img
+
+# Generate FAT32 eMMC image for OneNAND booting
+truncate -s 50MiB emmc_nand.img
+./mkfs.fat --mbr -F32 emmc_nand.img
+mcopy bootmenu_nand.scr ::/bootmenu.scr -i emmc_nand.img
+
+# Generate MTD image for RAM booting from bootloader nolo images, compiled image and rootfs image
+rm -f mtd_ram.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined.bin -r ubi.img -m rx51 -o mtd_ram.img
+
+# Generate MTD image for eMMC booting from bootloader nolo images, u-boot image and rootfs image
+rm -f mtd_emmc.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -r ubi.img -m rx51 -o mtd_emmc.img
+
+# Generate MTD image for OneNAND booting from bootloader nolo images, combined hacked image and rootfs image
+# Kernel image is put into initfs area, but qflasher reject to copy kernel image into initfs area because it does not have initfs signature
+# This is hack to workaround this problem, tell qflasher that kernel area for u-boot is bigger and put big combined hacked image (u-boot + kernel with correct offset)
+rm -f mtd_nand.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined_hack.bin -r ubi.img -m rx51 -p k=4094,i=2 -o mtd_nand.img
+
+echo
+echo
+echo "All images were successfully generated"
+echo "Now going to run them in qemu"
+echo
+echo
+
+# Run MTD image in qemu and wait for 300s if kernel from RAM is correctly booted
+rm -f qemu_ram.log
+./qemu-system-arm -M n900 -mtdblock mtd_ram.img -serial /dev/stdout -display none > qemu_ram.log &
+qemu_pid=$!
+tail -F qemu_ram.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from eMMC is correctly booted
+rm -f qemu_emmc.log
+./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial /dev/stdout -display none > qemu_emmc.log &
+qemu_pid=$!
+tail -F qemu_emmc.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from OneNAND is correctly booted
+rm -f qemu_nand.log
+./qemu-system-arm -M n900 -mtdblock mtd_nand.img -sd emmc_nand.img -serial /dev/stdout -display none > qemu_nand.log &
+qemu_pid=$!
+tail -F qemu_nand.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+echo
+echo
+if grep -q 'Successfully booted' qemu_ram.log; then echo "Kernel was successfully booted from RAM"; else echo "Failed to boot kernel from RAM"; fi
+if grep -q 'Successfully booted' qemu_emmc.log; then echo "Kernel was successfully booted from eMMC"; else echo "Failed to boot kernel from eMMC"; fi
+if grep -q 'Successfully booted' qemu_nand.log; then echo "Kernel was successfully booted from OneNAND"; else echo "Failed to boot kernel from OneNAND"; fi
+echo
+echo
+
+if grep -q 'Successfully booted' qemu_ram.log && grep -q 'Successfully booted' qemu_emmc.log && grep -q 'Successfully booted' qemu_nand.log; then
+	echo "All tests passed"
+	exit 0
+else
+	echo "Some tests failed"
+	exit 1
+fi
-- 
2.20.1

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> This patch contains a script which automatically download and compile all
> needed tools to build a simple MTD images for booting Maemo kernel image by
> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> machine provided by qemu-linaro project.
> 
> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> successfully booted in emulator.
> 
> Script is registered in to .travis.yml so it would be automatically run on
> Travi CI service.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Tom Rini, in past you have asked me for N900 Travis test. So could you
please review this patch (including fixup at the bottom)?

> ---
>  .travis.yml       |  10 +++
>  test/rx51_test.sh | 208 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 218 insertions(+)
>  create mode 100755 test/rx51_test.sh
> 
> diff --git a/.travis.yml b/.travis.yml
> index c59bd7790b..d96811473c 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -40,6 +40,8 @@ addons:
>      - clang-7
>      - srecord
>      - graphviz
> +    - mtools
> +    - mtd-utils
>  
>  install:
>   # Clone uboot-test-hooks
> @@ -116,6 +118,11 @@ script:
>   # Comments must be outside the command strings below, or the Travis parser
>   # will get confused.
>   #
> + # Run tests for Nokia RX-51 (aka N900)
> + - if [[ -n "${NOKIA_RX51}" ]]; then
> +     test/rx51_test.sh
> +     exit $?;
> +   fi
>   # From buildman, exit code 129 means warnings only.  If we've been asked to
>   # use clang only do one configuration.
>   - if [[ "${BUILDMAN}" != "" ]]; then
> @@ -160,6 +167,9 @@ matrix:
>    include:
>    # we need to build by vendor due to 50min time limit for builds
>    # each env setting here is a dedicated build
> +    - name: "nokia rx51"
> +      env:
> +        - NOKIA_RX51=1
>      - name: "buildman arc"
>        env:
>          - BUILDMAN="arc"
> diff --git a/test/rx51_test.sh b/test/rx51_test.sh
> new file mode 100755
> index 0000000000..43ecc07c08
> --- /dev/null
> +++ b/test/rx51_test.sh
> @@ -0,0 +1,208 @@
> +#!/bin/sh -e
> +# SPDX-License-Identifier: GPL-2.0+
> +# (C) 2020 Pali Roh?r <pali@kernel.org>
> +
> +# This test script depends on external tools:
> +# wget git truncate tar dpkg dd mcopy (from mtools) mkfs.ubifs (from mtd-utils) ubinize (from mtd-utils)
> +
> +# Download and compile linaro version qemu which has support for n900 machine
> +# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> +if ! test -f qemu-system-arm; then
> +	test -d qemu-linaro || git clone https://git.linaro.org/qemu/qemu-linaro.git
> +	cd qemu-linaro
> +	git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> +	./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list=pa,alsa --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
> +	make -j4
> +	cd ..
> +	ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
> +fi
> +
> +# Download and compile dosfstools with mbr support
> +# Currently this support is in open pull request 95
> +if ! test -f mkfs.fat; then
> +	test -d dosfstools || git clone https://github.com/dosfstools/dosfstools.git
> +	cd dosfstools
> +	git fetch origin refs/pull/95/head
> +	git checkout FETCH_HEAD
> +	./autogen.sh
> +	./configure
> +	make -j4
> +	cd ..
> +	ln -s dosfstools/src/mkfs.fat .
> +fi
> +
> +# Download qflasher and nolo images
> +# This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution
> +wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
> +tar -xf qemu-n900.tar.gz
> +
> +# Download Maemo script u-boot-gen-combined
> +if ! test -f u-boot-gen-combined; then
> +	test -d u-boot-maemo || git clone https://github.com/pali/u-boot-maemo.git
> +	chmod +x u-boot-maemo/debian/u-boot-gen-combined
> +	ln -s u-boot-maemo/debian/u-boot-gen-combined .
> +fi
> +
> +# Download Maemo fiasco kernel
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
> +dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
> +
> +# Download Maemo libc
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
> +dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
> +
> +# Download Maemo busybox
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
> +dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
> +
> +# Generate rootfs directory
> +# WARNING: there is "sudo mknod" call for /dev/console
> +mkdir -p rootfs
> +mkdir -p rootfs/dev/
> +mkdir -p rootfs/bin/
> +mkdir -p rootfs/sbin/
> +mkdir -p rootfs/lib/
> +test -c rootfs/dev/console || sudo mknod rootfs/dev/console c 5 1
> +cp -a busybox_1.10.2/bin/busybox rootfs/bin/
> +cp -a libc6_2.5.1/lib/ld-linux.so.3 rootfs/lib/
> +cp -a libc6_2.5.1/lib/ld-2.5.so rootfs/lib/
> +cp -a libc6_2.5.1/lib/libc.so.6 rootfs/lib/
> +cp -a libc6_2.5.1/lib/libc-2.5.so rootfs/lib/
> +cp -a libc6_2.5.1/lib/libcrypt.so.1 rootfs/lib/
> +cp -a libc6_2.5.1/lib/libcrypt-2.5.so rootfs/lib/
> +test -f rootfs/bin/sh || ln -sf busybox rootfs/bin/sh
> +test -f rootfs/sbin/poweroff || ln -sf ../bin/busybox rootfs/sbin/poweroff
> +cat > rootfs/sbin/preinit << EOF
> +#!/bin/sh
> +echo
> +echo "Successfully booted"
> +echo
> +/sbin/poweroff -f
> +EOF
> +chmod +x rootfs/sbin/preinit
> +
> +# Generate bootmenu for eMMC booting
> +cat > bootmenu_emmc << EOF
> +setenv bootmenu_0 'uImage-2.6.28-omap1 from eMMC=setenv mmcnum 1; setenv mmcpart 1; setenv mmctype fat; setenv bootargs; setenv setup_omap_atag 1; setenv mmckernfile uImage-2.6.28-omap1; run trymmckernboot';
> +setenv bootmenu_1;
> +setenv bootmenu_delay 1;
> +setenv bootdelay 1;
> +EOF
> +./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_emmc bootmenu_emmc.scr
> +
> +# Generate bootmenu for OneNAND booting
> +# FIXME: is address, size and offset really correct?
> +cat > bootmenu_nand << EOF
> +setenv bootmenu_0 'uImage-2.6.28-omap1 from OneNAND=mtd read initfs \${kernaddr} 0x800 0x1FF800; setenv bootargs; setenv setup_omap_atag 1; bootm \${kernaddr}';
> +setenv bootmenu_1;
> +setenv bootmenu_delay 1;
> +setenv bootdelay 1;
> +EOF
> +./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_nand bootmenu_nand.scr
> +
> +# Generate ubi config file for ubi rootfs image
> +cat > ubi.ini << EOF
> +[rootfs]
> +mode=ubi
> +image=ubifs.img
> +vol_id=0
> +vol_size=160MiB
> +vol_type=dynamic
> +vol_name=rootfs
> +vol_alignment=1
> +vol_flags=autoresize
> +EOF
> +
> +# Generate combined image from u-boot and Maemo fiasco kernel
> +dd if=kernel_2.6.28/boot/zImage-2.6.28-20103103+0m5.fiasco of=zImage-2.6.28-omap1 skip=95 bs=1
> +./mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage-2.6.28-omap1 -d zImage-2.6.28-omap1 uImage-2.6.28-omap1
> +./u-boot-gen-combined u-boot.bin uImage-2.6.28-omap1 combined.bin
> +
> +# Generate combined hack image from u-boot and Maemo fiasco kernel (kernel starts at 2MB offset)
> +cp u-boot.bin combined_hack.bin
> +dd if=uImage-2.6.28-omap1 of=combined_hack.bin bs=1024 seek=2048
> +
> +# Generate ubi rootfs image from rootfs directory
> +/usr/sbin/mkfs.ubifs -m 2048 -e 129024 -c 2047 -r rootfs ubifs.img
> +/usr/sbin/ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi.ini
> +
> +# Generate FAT32 eMMC image for eMMC booting
> +truncate -s 50MiB emmc_emmc.img
> +./mkfs.fat --mbr -F32 emmc_emmc.img
> +mcopy uImage-2.6.28-omap1 ::/uImage-2.6.28-omap1 -i emmc_emmc.img
> +mcopy bootmenu_emmc.scr ::/bootmenu.scr -i emmc_emmc.img
> +
> +# Generate FAT32 eMMC image for OneNAND booting
> +truncate -s 50MiB emmc_nand.img
> +./mkfs.fat --mbr -F32 emmc_nand.img
> +mcopy bootmenu_nand.scr ::/bootmenu.scr -i emmc_nand.img
> +
> +# Generate MTD image for RAM booting from bootloader nolo images, compiled image and rootfs image
> +rm -f mtd_ram.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined.bin -r ubi.img -m rx51 -o mtd_ram.img
> +
> +# Generate MTD image for eMMC booting from bootloader nolo images, u-boot image and rootfs image
> +rm -f mtd_emmc.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -r ubi.img -m rx51 -o mtd_emmc.img
> +
> +# Generate MTD image for OneNAND booting from bootloader nolo images, combined hacked image and rootfs image
> +# Kernel image is put into initfs area, but qflasher reject to copy kernel image into initfs area because it does not have initfs signature
> +# This is hack to workaround this problem, tell qflasher that kernel area for u-boot is bigger and put big combined hacked image (u-boot + kernel with correct offset)
> +rm -f mtd_nand.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined_hack.bin -r ubi.img -m rx51 -p k=4094,i=2 -o mtd_nand.img
> +
> +echo
> +echo
> +echo "All images were successfully generated"
> +echo "Now going to run them in qemu"
> +echo
> +echo
> +
> +# Run MTD image in qemu and wait for 300s if kernel from RAM is correctly booted
> +rm -f qemu_ram.log
> +./qemu-system-arm -M n900 -mtdblock mtd_ram.img -serial /dev/stdout -display none > qemu_ram.log &
> +qemu_pid=$!
> +tail -F qemu_ram.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +# Run MTD image in qemu and wait for 300s if kernel from eMMC is correctly booted
> +rm -f qemu_emmc.log
> +./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial /dev/stdout -display none > qemu_emmc.log &
> +qemu_pid=$!
> +tail -F qemu_emmc.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +# Run MTD image in qemu and wait for 300s if kernel from OneNAND is correctly booted
> +rm -f qemu_nand.log
> +./qemu-system-arm -M n900 -mtdblock mtd_nand.img -sd emmc_nand.img -serial /dev/stdout -display none > qemu_nand.log &
> +qemu_pid=$!
> +tail -F qemu_nand.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +echo
> +echo
> +if grep -q 'Successfully booted' qemu_ram.log; then echo "Kernel was successfully booted from RAM"; else echo "Failed to boot kernel from RAM"; fi
> +if grep -q 'Successfully booted' qemu_emmc.log; then echo "Kernel was successfully booted from eMMC"; else echo "Failed to boot kernel from eMMC"; fi
> +if grep -q 'Successfully booted' qemu_nand.log; then echo "Kernel was successfully booted from OneNAND"; else echo "Failed to boot kernel from OneNAND"; fi
> +echo
> +echo
> +
> +if grep -q 'Successfully booted' qemu_ram.log && grep -q 'Successfully booted' qemu_emmc.log && grep -q 'Successfully booted' qemu_nand.log; then
> +	echo "All tests passed"
> +	exit 0
> +else
> +	echo "Some tests failed"
> +	exit 1
> +fi
> -- 
> 2.20.1
> 

This change needs following fixup:
https://github.com/u-boot/u-boot/commit/2ace522bba40b70a26950e7d4b033fd10740dad0

and with it N900 test on Travis passed:
https://travis-ci.org/github/u-boot/u-boot/jobs/669672160

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Lokesh Vutla]

Tom,

On 14/04/20 4:10 PM, Pali Roh?r wrote:
> On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
>> This patch contains a script which automatically download and compile all
>> needed tools to build a simple MTD images for booting Maemo kernel image by
>> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
>> machine provided by qemu-linaro project.
>>
>> It can be used to check that U-Boot for Nokia N900 is not broken and can be
>> successfully booted in emulator.
>>
>> Script is registered in to .travis.yml so it would be automatically run on
>> Travi CI service.
>>
>> Signed-off-by: Pali Roh?r <pali@kernel.org>
> 
> Tom Rini, in past you have asked me for N900 Travis test. So could you
> please review this patch (including fixup at the bottom)?

Can you ack this patch?

Thanks and regards,
Lokesh

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Simon Glass]

Hi,

On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
>
> Tom,
>
> On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> >> This patch contains a script which automatically download and compile all
> >> needed tools to build a simple MTD images for booting Maemo kernel image by
> >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> >> machine provided by qemu-linaro project.
> >>
> >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> >> successfully booted in emulator.
> >>
> >> Script is registered in to .travis.yml so it would be automatically run on
> >> Travi CI service.
> >>
> >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> >
> > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > please review this patch (including fixup at the bottom)?
>
> Can you ack this patch?

Please use a pytest for this (test/py). We don't use shell scripts anymore.

Regards,
Simon

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> Hi,
> 
> On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> >
> > Tom,
> >
> > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > >> This patch contains a script which automatically download and compile all
> > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > >> machine provided by qemu-linaro project.
> > >>
> > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > >> successfully booted in emulator.
> > >>
> > >> Script is registered in to .travis.yml so it would be automatically run on
> > >> Travi CI service.
> > >>
> > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > >
> > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > please review this patch (including fixup at the bottom)?
> >
> > Can you ack this patch?
> 
> Please use a pytest for this (test/py). We don't use shell scripts anymore.

Well, this is where it's tricky and I've been debating with myself on
how to move forward here.

Part of the problem here is that much like a Pi, we could emulate this
board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
there's not a lot of these devices around to test with.  It's not a big
deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
has a Pi and other labs could add one fairly easy.  But adding an N900
to a lab is hard.

Looking over the script to do it, there's a lot of other stuff required
too, for it all to work.  Looking over the script again, there's enough
stuff going on that I wouldn't want it done in a persistent
image/container.

The only changes I would ask for I guess are that it should be put in
.travis.yml in the same areas other non-pytest tests, and put in similar
stanzas in .azure-ci.yml and .gitlab-ci.yml.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200421/0a023340/attachment.sig>

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Simon Glass]

Hi,

On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > >
> > > Tom,
> > >
> > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > >> This patch contains a script which automatically download and compile all
> > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > >> machine provided by qemu-linaro project.
> > > >>
> > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > >> successfully booted in emulator.
> > > >>
> > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > >> Travi CI service.
> > > >>
> > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > >
> > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > please review this patch (including fixup at the bottom)?
> > >
> > > Can you ack this patch?
> >
> > Please use a pytest for this (test/py). We don't use shell scripts anymore.
>
> Well, this is where it's tricky and I've been debating with myself on
> how to move forward here.
>
> Part of the problem here is that much like a Pi, we could emulate this
> board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> there's not a lot of these devices around to test with.  It's not a big
> deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> has a Pi and other labs could add one fairly easy.  But adding an N900
> to a lab is hard.
>
> Looking over the script to do it, there's a lot of other stuff required
> too, for it all to work.  Looking over the script again, there's enough
> stuff going on that I wouldn't want it done in a persistent
> image/container.
>
> The only changes I would ask for I guess are that it should be put in
> .travis.yml in the same areas other non-pytest tests, and put in similar
> stanzas in .azure-ci.yml and .gitlab-ci.yml.

For the existing stuff we use some sort of qemu that is built into the
image, so far as I understand it. Is that right?

Could we do something similar here? I actually don't like that though,
since there is so much setup needed to run things locally (without
docker).

Also, what is to stop me running this script on my machine?

Regards,
Simon

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> Hi,
> 
> On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > >
> > > > Tom,
> > > >
> > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > >> This patch contains a script which automatically download and compile all
> > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > >> machine provided by qemu-linaro project.
> > > > >>
> > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > >> successfully booted in emulator.
> > > > >>
> > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > >> Travi CI service.
> > > > >>
> > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > >
> > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > please review this patch (including fixup at the bottom)?
> > > >
> > > > Can you ack this patch?
> > >
> > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> >
> > Well, this is where it's tricky and I've been debating with myself on
> > how to move forward here.
> >
> > Part of the problem here is that much like a Pi, we could emulate this
> > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > there's not a lot of these devices around to test with.  It's not a big
> > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > has a Pi and other labs could add one fairly easy.  But adding an N900
> > to a lab is hard.
> >
> > Looking over the script to do it, there's a lot of other stuff required
> > too, for it all to work.  Looking over the script again, there's enough
> > stuff going on that I wouldn't want it done in a persistent
> > image/container.
> >
> > The only changes I would ask for I guess are that it should be put in
> > .travis.yml in the same areas other non-pytest tests, and put in similar
> > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> 
> For the existing stuff we use some sort of qemu that is built into the
> image, so far as I understand it. Is that right?

Right for GitLab/Azure, for Travis we checkout/build/install.

> Could we do something similar here? I actually don't like that though,
> since there is so much setup needed to run things locally (without
> docker).

That's what the script does.  The problem is that we need a specific
(seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
we can't replace the QEMU we use for everyone with one that also
supports N900.

> Also, what is to stop me running this script on my machine?

Nothing.  And it does a good job of keeping all of the specific versions
of stuff it needs local to itself.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200421/5bfad04d/attachment.sig>

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Simon Glass]

Hi Tom,

On Tue, 21 Apr 2020 at 14:46, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > > >
> > > > > Tom,
> > > > >
> > > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > > >> This patch contains a script which automatically download and compile all
> > > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > > >> machine provided by qemu-linaro project.
> > > > > >>
> > > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > > >> successfully booted in emulator.
> > > > > >>
> > > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > > >> Travi CI service.
> > > > > >>
> > > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > > >
> > > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > > please review this patch (including fixup at the bottom)?
> > > > >
> > > > > Can you ack this patch?
> > > >
> > > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> > >
> > > Well, this is where it's tricky and I've been debating with myself on
> > > how to move forward here.
> > >
> > > Part of the problem here is that much like a Pi, we could emulate this
> > > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > > there's not a lot of these devices around to test with.  It's not a big
> > > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > > has a Pi and other labs could add one fairly easy.  But adding an N900
> > > to a lab is hard.
> > >
> > > Looking over the script to do it, there's a lot of other stuff required
> > > too, for it all to work.  Looking over the script again, there's enough
> > > stuff going on that I wouldn't want it done in a persistent
> > > image/container.
> > >
> > > The only changes I would ask for I guess are that it should be put in
> > > .travis.yml in the same areas other non-pytest tests, and put in similar
> > > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> >
> > For the existing stuff we use some sort of qemu that is built into the
> > image, so far as I understand it. Is that right?
>
> Right for GitLab/Azure, for Travis we checkout/build/install.
>
> > Could we do something similar here? I actually don't like that though,
> > since there is so much setup needed to run things locally (without
> > docker).
>
> That's what the script does.  The problem is that we need a specific
> (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
> we can't replace the QEMU we use for everyone with one that also
> supports N900.

OK I see.

>
> > Also, what is to stop me running this script on my machine?
>
> Nothing.  And it does a good job of keeping all of the specific versions
> of stuff it needs local to itself.

OK, so you don't think we should add this as a pytest?

Regards,
Simon

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Tue, Apr 21, 2020 at 02:49:05PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 21 Apr 2020 at 14:46, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > > > >
> > > > > > Tom,
> > > > > >
> > > > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > > > >> This patch contains a script which automatically download and compile all
> > > > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > > > >> machine provided by qemu-linaro project.
> > > > > > >>
> > > > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > > > >> successfully booted in emulator.
> > > > > > >>
> > > > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > > > >> Travi CI service.
> > > > > > >>
> > > > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > > > >
> > > > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > > > please review this patch (including fixup at the bottom)?
> > > > > >
> > > > > > Can you ack this patch?
> > > > >
> > > > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> > > >
> > > > Well, this is where it's tricky and I've been debating with myself on
> > > > how to move forward here.
> > > >
> > > > Part of the problem here is that much like a Pi, we could emulate this
> > > > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > > > there's not a lot of these devices around to test with.  It's not a big
> > > > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > > > has a Pi and other labs could add one fairly easy.  But adding an N900
> > > > to a lab is hard.
> > > >
> > > > Looking over the script to do it, there's a lot of other stuff required
> > > > too, for it all to work.  Looking over the script again, there's enough
> > > > stuff going on that I wouldn't want it done in a persistent
> > > > image/container.
> > > >
> > > > The only changes I would ask for I guess are that it should be put in
> > > > .travis.yml in the same areas other non-pytest tests, and put in similar
> > > > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> > >
> > > For the existing stuff we use some sort of qemu that is built into the
> > > image, so far as I understand it. Is that right?
> >
> > Right for GitLab/Azure, for Travis we checkout/build/install.
> >
> > > Could we do something similar here? I actually don't like that though,
> > > since there is so much setup needed to run things locally (without
> > > docker).
> >
> > That's what the script does.  The problem is that we need a specific
> > (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
> > we can't replace the QEMU we use for everyone with one that also
> > supports N900.
> 
> OK I see.
> 
> >
> > > Also, what is to stop me running this script on my machine?
> >
> > Nothing.  And it does a good job of keeping all of the specific versions
> > of stuff it needs local to itself.
> 
> OK, so you don't think we should add this as a pytest?

No, I don't think wrapping this as a pytest would be valuable.  Re-doing
the FS tests is a step towards being able to run them on at least
emulated HW too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200421/ccdc9878/attachment.sig>

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 21 April 2020 16:51:23 Tom Rini wrote:
> On Tue, Apr 21, 2020 at 02:49:05PM -0600, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Tue, 21 Apr 2020 at 14:46, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > > > > >> This patch contains a script which automatically download and compile all
> > > > > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > > > > >> machine provided by qemu-linaro project.
> > > > > > > >>
> > > > > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > > > > >> successfully booted in emulator.
> > > > > > > >>
> > > > > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > > > > >> Travi CI service.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > > > > >
> > > > > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > > > > please review this patch (including fixup at the bottom)?
> > > > > > >
> > > > > > > Can you ack this patch?
> > > > > >
> > > > > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> > > > >
> > > > > Well, this is where it's tricky and I've been debating with myself on
> > > > > how to move forward here.
> > > > >
> > > > > Part of the problem here is that much like a Pi, we could emulate this
> > > > > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > > > > there's not a lot of these devices around to test with.  It's not a big
> > > > > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > > > > has a Pi and other labs could add one fairly easy.  But adding an N900
> > > > > to a lab is hard.
> > > > >
> > > > > Looking over the script to do it, there's a lot of other stuff required
> > > > > too, for it all to work.  Looking over the script again, there's enough
> > > > > stuff going on that I wouldn't want it done in a persistent
> > > > > image/container.
> > > > >
> > > > > The only changes I would ask for I guess are that it should be put in
> > > > > .travis.yml in the same areas other non-pytest tests, and put in similar
> > > > > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> > > >
> > > > For the existing stuff we use some sort of qemu that is built into the
> > > > image, so far as I understand it. Is that right?
> > >
> > > Right for GitLab/Azure, for Travis we checkout/build/install.
> > >
> > > > Could we do something similar here? I actually don't like that though,
> > > > since there is so much setup needed to run things locally (without
> > > > docker).
> > >
> > > That's what the script does.  The problem is that we need a specific
> > > (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
> > > we can't replace the QEMU we use for everyone with one that also
> > > supports N900.
> > 
> > OK I see.
> > 
> > >
> > > > Also, what is to stop me running this script on my machine?
> > >
> > > Nothing.  And it does a good job of keeping all of the specific versions
> > > of stuff it needs local to itself.
> > 
> > OK, so you don't think we should add this as a pytest?
> 
> No, I don't think wrapping this as a pytest would be valuable.  Re-doing
> the FS tests is a step towards being able to run them on at least
> emulated HW too.

Ok, so is something needed to do with this patch?

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Roh?r wrote:
> On Tuesday 21 April 2020 16:51:23 Tom Rini wrote:
> > On Tue, Apr 21, 2020 at 02:49:05PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > > 
> > > On Tue, 21 Apr 2020 at 14:46, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > > > > > >
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > > > > > >> This patch contains a script which automatically download and compile all
> > > > > > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > > > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > > > > > >> machine provided by qemu-linaro project.
> > > > > > > > >>
> > > > > > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > > > > > >> successfully booted in emulator.
> > > > > > > > >>
> > > > > > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > > > > > >> Travi CI service.
> > > > > > > > >>
> > > > > > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > > > > > >
> > > > > > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > > > > > please review this patch (including fixup at the bottom)?
> > > > > > > >
> > > > > > > > Can you ack this patch?
> > > > > > >
> > > > > > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> > > > > >
> > > > > > Well, this is where it's tricky and I've been debating with myself on
> > > > > > how to move forward here.
> > > > > >
> > > > > > Part of the problem here is that much like a Pi, we could emulate this
> > > > > > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > > > > > there's not a lot of these devices around to test with.  It's not a big
> > > > > > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > > > > > has a Pi and other labs could add one fairly easy.  But adding an N900
> > > > > > to a lab is hard.
> > > > > >
> > > > > > Looking over the script to do it, there's a lot of other stuff required
> > > > > > too, for it all to work.  Looking over the script again, there's enough
> > > > > > stuff going on that I wouldn't want it done in a persistent
> > > > > > image/container.
> > > > > >
> > > > > > The only changes I would ask for I guess are that it should be put in
> > > > > > .travis.yml in the same areas other non-pytest tests, and put in similar
> > > > > > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> > > > >
> > > > > For the existing stuff we use some sort of qemu that is built into the
> > > > > image, so far as I understand it. Is that right?
> > > >
> > > > Right for GitLab/Azure, for Travis we checkout/build/install.
> > > >
> > > > > Could we do something similar here? I actually don't like that though,
> > > > > since there is so much setup needed to run things locally (without
> > > > > docker).
> > > >
> > > > That's what the script does.  The problem is that we need a specific
> > > > (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
> > > > we can't replace the QEMU we use for everyone with one that also
> > > > supports N900.
> > > 
> > > OK I see.
> > > 
> > > >
> > > > > Also, what is to stop me running this script on my machine?
> > > >
> > > > Nothing.  And it does a good job of keeping all of the specific versions
> > > > of stuff it needs local to itself.
> > > 
> > > OK, so you don't think we should add this as a pytest?
> > 
> > No, I don't think wrapping this as a pytest would be valuable.  Re-doing
> > the FS tests is a step towards being able to run them on at least
> > emulated HW too.
> 
> Ok, so is something needed to do with this patch?

Yes, re-order where the .travis.yml hunk is and add a similar part to
.gitlab-ci.yml and .azure-ci.yml.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200421/7e7c4b43/attachment.sig>

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 21 April 2020 19:24:57 Tom Rini wrote:
> On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Roh?r wrote:
> > Ok, so is something needed to do with this patch?
> 
> Yes, re-order where the .travis.yml hunk is and add a similar part to
> .gitlab-ci.yml and .azure-ci.yml.

Hello Tom! I have looked at .travis.yml again, but I do not understand
what do you mean by re-order. I really have no idea where you want to
move that rx51_test.sh hunk. Could you describe it?

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Thu, Apr 23, 2020 at 09:34:26AM +0200, Pali Roh?r wrote:
> On Tuesday 21 April 2020 19:24:57 Tom Rini wrote:
> > On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Roh?r wrote:
> > > Ok, so is something needed to do with this patch?
> > 
> > Yes, re-order where the .travis.yml hunk is and add a similar part to
> > .gitlab-ci.yml and .azure-ci.yml.
> 
> Hello Tom! I have looked at .travis.yml again, but I do not understand
> what do you mean by re-order. I really have no idea where you want to
> move that rx51_test.sh hunk. Could you describe it?

This should go around where we check tools-only/envtools.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200423/83b3815b/attachment.sig>

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Thursday 23 April 2020 08:24:05 Tom Rini wrote:
> On Thu, Apr 23, 2020 at 09:34:26AM +0200, Pali Roh?r wrote:
> > On Tuesday 21 April 2020 19:24:57 Tom Rini wrote:
> > > On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Roh?r wrote:
> > > > Ok, so is something needed to do with this patch?
> > > 
> > > Yes, re-order where the .travis.yml hunk is and add a similar part to
> > > .gitlab-ci.yml and .azure-ci.yml.
> > 
> > Hello Tom! I have looked at .travis.yml again, but I do not understand
> > what do you mean by re-order. I really have no idea where you want to
> > move that rx51_test.sh hunk. Could you describe it?
> 
> This should go around where we check tools-only/envtools.  Thanks!

Thank you, now I figured out. I will send V2 of this one patch.

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

This patch contains test/nokia_rx51_test.sh script which automatically
download and compile all needed tools in local temporary directory to
generate a simple MTD images for booting Maemo kernel image by U-Boot from
RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
provided by qemu-linaro project.

This script does not need any special privileges, so it can be run as
non-root nobody user.

It can be used to check that U-Boot for Nokia N900 is not broken and can be
successfully booted in emulator.

Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
.travis.yml so it would be automatically run on those CI services.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
Changes in v2:
* Fix apt dependences for Travis CI
* Move definition of Travis job into own section
* Add definition for Azure and Gitlab CI services
* Add script to MAINTAINERS file
* Build U-Boot binary in test script too
* Show error message when some dependency for script is missing
* Fix addresses for booting kernel from OneNAND
* Do all stuff in nokia_rx51_tmp temporary directory
* Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
  (instead of mkfs.fat from dosfstools with custom patches)
* Show more verbose log messages
* Do not use sudo, instead run parts of script under fakeroot
  (fakeroot just run binary with own LD_PRELOAD library which emulates
   mknod() function for later usage by stat() function)
* So script can be now run as non-root nobody user and it put all stuff
  in nokia_rx51_tmp temporary directory, so can be run locally without
  any issue.
---
 .azure-pipelines.yml         |   7 +
 .gitlab-ci.yml               |   6 +
 .travis.yml                  |   7 +
 board/nokia/rx51/MAINTAINERS |   1 +
 test/nokia_rx51_test.sh      | 262 +++++++++++++++++++++++++++++++++++
 5 files changed, 283 insertions(+)
 create mode 100755 test/nokia_rx51_test.sh

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index d3e7b4dd02..a812f7f906 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -151,6 +151,13 @@ jobs:
           # seems to hang forever with pre-configured "container" environment
           docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh
 
+  - job: nokia_rx51_test
+    displayName: 'Run tests for Nokia RX-51 (aka N900)'
+    pool:
+      vmImage: $(ubuntu_vm)
+    steps:
+      - script: test/nokia_rx51_test.sh
+
   - job: test_py
     displayName: 'test.py'
     pool:
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 08bdf81e74..678f4323a0 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -170,6 +170,12 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
       ./tools/patman/patman --test;
       make testconfig
 
+Run tests for Nokia RX-51 (aka N900):
+  tags: [ 'all' ]
+  stage: testsuites
+  script:
+    - test/nokia_rx51_test.sh
+
 # Test sandbox with test.py
 sandbox test.py:
   tags: [ 'all' ]
diff --git a/.travis.yml b/.travis.yml
index 82e3b91523..b32555d89f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -49,6 +49,8 @@ addons:
     - mtools
     - openssl
     - sbsigntool
+    - fakeroot
+    - mtd-utils
 
 install:
  # Clone uboot-test-hooks
@@ -491,6 +493,11 @@ matrix:
       script:
         - make tools-only_config envtools -j$(nproc)
 
+    - name: "Run tests for Nokia RX-51 (aka N900)"
+      script:
+        - export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
+        - test/nokia_rx51_test.sh
+
     # test/py
     - name: "test/py sandbox"
       env:
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index f2a712620b..58b16bf9a9 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -5,3 +5,4 @@ F:	board/nokia/rx51/
 F:	include/configs/nokia_rx51.h
 F:	configs/nokia_rx51_defconfig
 F:	doc/README.nokia_rx51
+F:	test/nokia_rx51_test.sh
diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh
new file mode 100755
index 0000000000..a5b6a9d565
--- /dev/null
+++ b/test/nokia_rx51_test.sh
@@ -0,0 +1,262 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: GPL-2.0+
+# (C) 2020 Pali Roh?r <pali@kernel.org>
+
+# External tools needed for this test:
+echo '
+	wget
+	git
+	truncate
+	tar
+	dpkg
+	dd
+	make
+	gcc
+	arm-linux-gnueabi-gcc
+	fakeroot		(homepage http://fakeroot-ng.lingnu.com/)
+	mcopy			(from mtools, homepage http://www.gnu.org/software/mtools/)
+	mformat			(from mtools, homepage http://www.gnu.org/software/mtools/)
+	/usr/sbin/mkfs.ubifs	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
+	/usr/sbin/ubinize	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
+' | while read tool info; do
+	if test -z "$tool"; then continue; fi
+	if ! which $tool 1>/dev/null 2>&1; then
+		echo "Tool $tool was not found and is required to run this test"
+		echo "First install $tool $info"
+		exit 1
+	fi
+done || exit 1
+
+echo
+echo "============================================================"
+echo "========== Compiling U-Boot for Nokia RX-51 board =========="
+echo "============================================================"
+echo
+
+# First compile u-boot.bin binary for Nokia RX-51 board
+make nokia_rx51_config
+make -j4 u-boot.bin ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
+
+# And then do all stuff in temporary directory
+mkdir -p nokia_rx51_tmp
+cd nokia_rx51_tmp
+
+test -f mkimage || ln -s ../tools/mkimage .
+test -f u-boot.bin || ln -s ../u-boot.bin .
+
+echo
+echo "=========================================================================="
+echo "========== Downloading and compiling qemu from qemu-linaro fork =========="
+echo "=========================================================================="
+echo
+
+# Download and compile linaro version qemu which has support for n900 machine
+# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+if ! test -f qemu-system-arm; then
+	test -d qemu-linaro || git clone https://git.linaro.org/qemu/qemu-linaro.git
+	cd qemu-linaro
+	git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+	./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list= --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
+	make -j4
+	cd ..
+	ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
+fi
+
+echo
+echo "==================================================="
+echo "========== Downloading external binaries =========="
+echo "==================================================="
+echo
+
+# Download qflasher and nolo images
+# This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution
+wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
+tar -xf qemu-n900.tar.gz
+
+# Download Maemo script u-boot-gen-combined
+if ! test -f u-boot-gen-combined; then
+	test -d u-boot-maemo || git clone https://github.com/pali/u-boot-maemo.git
+	chmod +x u-boot-maemo/debian/u-boot-gen-combined
+	ln -s u-boot-maemo/debian/u-boot-gen-combined .
+fi
+
+# Download Maemo fiasco kernel
+wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
+
+# Download Maemo libc
+wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
+dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
+
+# Download Maemo busybox
+wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
+dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
+
+echo
+echo "======================================="
+echo "========== Generating images =========="
+echo "======================================="
+echo
+
+# Generate rootfs directory
+mkdir -p rootfs
+mkdir -p rootfs/dev/
+mkdir -p rootfs/bin/
+mkdir -p rootfs/sbin/
+mkdir -p rootfs/lib/
+cp -a busybox_1.10.2/bin/busybox rootfs/bin/
+cp -a libc6_2.5.1/lib/ld-linux.so.3 rootfs/lib/
+cp -a libc6_2.5.1/lib/ld-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libc.so.6 rootfs/lib/
+cp -a libc6_2.5.1/lib/libc-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt.so.1 rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt-2.5.so rootfs/lib/
+test -f rootfs/bin/sh || ln -sf busybox rootfs/bin/sh
+test -f rootfs/sbin/poweroff || ln -sf ../bin/busybox rootfs/sbin/poweroff
+cat > rootfs/sbin/preinit << EOF
+#!/bin/sh
+echo
+echo "Successfully booted"
+echo
+/sbin/poweroff -f
+EOF
+chmod +x rootfs/sbin/preinit
+
+# Generate ubi config file for ubi rootfs image
+cat > ubi.ini << EOF
+[rootfs]
+mode=ubi
+image=ubifs.img
+vol_id=0
+vol_size=160MiB
+vol_type=dynamic
+vol_name=rootfs
+vol_alignment=1
+vol_flags=autoresize
+EOF
+
+# Generate ubi rootfs image from rootfs directory
+# NOTE: Character device on host filesystem can be created only by root
+#       But we do not need it on host filesystem, just in ubifs image
+#       So run mknod and mkfs.ubifs commands under fakeroot program
+#       which via LD_PRELOAD simulate mknod() and stat() functions
+#       so mkfs.ubifs will see dev/console as character device and
+#       put it correctly as character device into final ubifs image
+#       Therefore we can run whole script as non-root nobody user
+fakeroot sh -c '
+	rm -f rootfs/dev/console;
+	mknod rootfs/dev/console c 5 1;
+	/usr/sbin/mkfs.ubifs -m 2048 -e 129024 -c 2047 -r rootfs ubifs.img;
+'
+/usr/sbin/ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi.ini
+
+# Generate bootmenu for eMMC booting
+cat > bootmenu_emmc << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from eMMC=setenv mmcnum 1; setenv mmcpart 1; setenv mmctype fat; setenv bootargs; setenv setup_omap_atag 1; setenv mmckernfile uImage-2.6.28-omap1; run trymmckernboot';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_emmc bootmenu_emmc.scr
+
+# Generate bootmenu for OneNAND booting
+cat > bootmenu_nand << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from OneNAND=mtd read initfs \${kernaddr}; setenv bootargs; setenv setup_omap_atag 1; bootm \${kernaddr}';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_nand bootmenu_nand.scr
+
+# Generate combined image from u-boot and Maemo fiasco kernel
+dd if=kernel_2.6.28/boot/zImage-2.6.28-20103103+0m5.fiasco of=zImage-2.6.28-omap1 skip=95 bs=1
+./mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage-2.6.28-omap1 -d zImage-2.6.28-omap1 uImage-2.6.28-omap1
+./u-boot-gen-combined u-boot.bin uImage-2.6.28-omap1 combined.bin
+
+# Generate combined hack image from u-boot and Maemo fiasco kernel (kernel starts@2MB offset and qflasher puts 2kB header before supplied image)
+cp u-boot.bin combined_hack.bin
+dd if=uImage-2.6.28-omap1 of=combined_hack.bin bs=1024 seek=$((2048-2))
+
+# Generate FAT32 eMMC image for eMMC booting
+truncate -s 50MiB emmc_emmc.img
+mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_emmc.img
+mcopy uImage-2.6.28-omap1 ::/uImage-2.6.28-omap1 -i emmc_emmc.img
+mcopy bootmenu_emmc.scr ::/bootmenu.scr -i emmc_emmc.img
+
+# Generate FAT32 eMMC image for OneNAND booting
+truncate -s 50MiB emmc_nand.img
+mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_nand.img
+mcopy bootmenu_nand.scr ::/bootmenu.scr -i emmc_nand.img
+
+# Generate MTD image for RAM booting from bootloader nolo images, compiled image and rootfs image
+rm -f mtd_ram.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined.bin -r ubi.img -m rx51 -o mtd_ram.img
+
+# Generate MTD image for eMMC booting from bootloader nolo images, u-boot image and rootfs image
+rm -f mtd_emmc.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -r ubi.img -m rx51 -o mtd_emmc.img
+
+# Generate MTD image for OneNAND booting from bootloader nolo images, combined hacked image and rootfs image
+# Kernel image is put into initfs area, but qflasher reject to copy kernel image into initfs area because it does not have initfs signature
+# This is hack to workaround this problem, tell qflasher that kernel area for u-boot is bigger and put big combined hacked image (u-boot + kernel with correct offset)
+rm -f mtd_nand.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined_hack.bin -r ubi.img -m rx51 -p k=4094,i=2 -o mtd_nand.img
+
+echo
+echo "======================================================"
+echo "========== Running test images in n900 qemu =========="
+echo "======================================================"
+echo
+
+# Run MTD image in qemu and wait for 300s if kernel from RAM is correctly booted
+rm -f qemu_ram.log
+./qemu-system-arm -M n900 -mtdblock mtd_ram.img -serial /dev/stdout -display none > qemu_ram.log &
+qemu_pid=$!
+tail -F qemu_ram.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from eMMC is correctly booted
+rm -f qemu_emmc.log
+./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial /dev/stdout -display none > qemu_emmc.log &
+qemu_pid=$!
+tail -F qemu_emmc.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from OneNAND is correctly booted
+rm -f qemu_nand.log
+./qemu-system-arm -M n900 -mtdblock mtd_nand.img -sd emmc_nand.img -serial /dev/stdout -display none > qemu_nand.log &
+qemu_pid=$!
+tail -F qemu_nand.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+echo
+echo "============================="
+echo "========== Results =========="
+echo "============================="
+echo
+
+if grep -q 'Successfully booted' qemu_ram.log; then echo "Kernel was successfully booted from RAM"; else echo "Failed to boot kernel from RAM"; fi
+if grep -q 'Successfully booted' qemu_emmc.log; then echo "Kernel was successfully booted from eMMC"; else echo "Failed to boot kernel from eMMC"; fi
+if grep -q 'Successfully booted' qemu_nand.log; then echo "Kernel was successfully booted from OneNAND"; else echo "Failed to boot kernel from OneNAND"; fi
+
+echo
+
+if grep -q 'Successfully booted' qemu_ram.log && grep -q 'Successfully booted' qemu_emmc.log && grep -q 'Successfully booted' qemu_nand.log; then
+	echo "All tests passed"
+	exit 0
+else
+	echo "Some tests failed"
+	exit 1
+fi
-- 
2.20.1

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Saturday 25 April 2020 11:00:06 Pali Roh?r wrote:
> This patch contains test/nokia_rx51_test.sh script which automatically
> download and compile all needed tools in local temporary directory to
> generate a simple MTD images for booting Maemo kernel image by U-Boot from
> RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
> provided by qemu-linaro project.
> 
> This script does not need any special privileges, so it can be run as
> non-root nobody user.
> 
> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> successfully booted in emulator.
> 
> Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
> .travis.yml so it would be automatically run on those CI services.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>

Hello Tom, could you please review this new patch with testing script?

With strto patch, script passed on Travis CI:
https://travis-ci.org/github/u-boot/u-boot/jobs/679162986

Are there any other issues or could be this patch series accepted and
merged?

> ---
> Changes in v2:
> * Fix apt dependences for Travis CI
> * Move definition of Travis job into own section
> * Add definition for Azure and Gitlab CI services
> * Add script to MAINTAINERS file
> * Build U-Boot binary in test script too
> * Show error message when some dependency for script is missing
> * Fix addresses for booting kernel from OneNAND
> * Do all stuff in nokia_rx51_tmp temporary directory
> * Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
>   (instead of mkfs.fat from dosfstools with custom patches)
> * Show more verbose log messages
> * Do not use sudo, instead run parts of script under fakeroot
>   (fakeroot just run binary with own LD_PRELOAD library which emulates
>    mknod() function for later usage by stat() function)
> * So script can be now run as non-root nobody user and it put all stuff
>   in nokia_rx51_tmp temporary directory, so can be run locally without
>   any issue.
> ---
>  .azure-pipelines.yml         |   7 +
>  .gitlab-ci.yml               |   6 +
>  .travis.yml                  |   7 +
>  board/nokia/rx51/MAINTAINERS |   1 +
>  test/nokia_rx51_test.sh      | 262 +++++++++++++++++++++++++++++++++++
>  5 files changed, 283 insertions(+)
>  create mode 100755 test/nokia_rx51_test.sh
> 
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index d3e7b4dd02..a812f7f906 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -151,6 +151,13 @@ jobs:
>            # seems to hang forever with pre-configured "container" environment
>            docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh
>  
> +  - job: nokia_rx51_test
> +    displayName: 'Run tests for Nokia RX-51 (aka N900)'
> +    pool:
> +      vmImage: $(ubuntu_vm)
> +    steps:
> +      - script: test/nokia_rx51_test.sh
> +
>    - job: test_py
>      displayName: 'test.py'
>      pool:
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 08bdf81e74..678f4323a0 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -170,6 +170,12 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
>        ./tools/patman/patman --test;
>        make testconfig
>  
> +Run tests for Nokia RX-51 (aka N900):
> +  tags: [ 'all' ]
> +  stage: testsuites
> +  script:
> +    - test/nokia_rx51_test.sh
> +
>  # Test sandbox with test.py
>  sandbox test.py:
>    tags: [ 'all' ]
> diff --git a/.travis.yml b/.travis.yml
> index 82e3b91523..b32555d89f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -49,6 +49,8 @@ addons:
>      - mtools
>      - openssl
>      - sbsigntool
> +    - fakeroot
> +    - mtd-utils
>  
>  install:
>   # Clone uboot-test-hooks
> @@ -491,6 +493,11 @@ matrix:
>        script:
>          - make tools-only_config envtools -j$(nproc)
>  
> +    - name: "Run tests for Nokia RX-51 (aka N900)"
> +      script:
> +        - export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> +        - test/nokia_rx51_test.sh
> +
>      # test/py
>      - name: "test/py sandbox"
>        env:
> diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
> index f2a712620b..58b16bf9a9 100644
> --- a/board/nokia/rx51/MAINTAINERS
> +++ b/board/nokia/rx51/MAINTAINERS
> @@ -5,3 +5,4 @@ F:	board/nokia/rx51/
>  F:	include/configs/nokia_rx51.h
>  F:	configs/nokia_rx51_defconfig
>  F:	doc/README.nokia_rx51
> +F:	test/nokia_rx51_test.sh
> diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh
> new file mode 100755
> index 0000000000..a5b6a9d565
> --- /dev/null
> +++ b/test/nokia_rx51_test.sh
> @@ -0,0 +1,262 @@
> +#!/bin/sh -e
> +# SPDX-License-Identifier: GPL-2.0+
> +# (C) 2020 Pali Roh?r <pali@kernel.org>
> +
> +# External tools needed for this test:
> +echo '
> +	wget
> +	git
> +	truncate
> +	tar
> +	dpkg
> +	dd
> +	make
> +	gcc
> +	arm-linux-gnueabi-gcc
> +	fakeroot		(homepage http://fakeroot-ng.lingnu.com/)
> +	mcopy			(from mtools, homepage http://www.gnu.org/software/mtools/)
> +	mformat			(from mtools, homepage http://www.gnu.org/software/mtools/)
> +	/usr/sbin/mkfs.ubifs	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
> +	/usr/sbin/ubinize	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
> +' | while read tool info; do
> +	if test -z "$tool"; then continue; fi
> +	if ! which $tool 1>/dev/null 2>&1; then
> +		echo "Tool $tool was not found and is required to run this test"
> +		echo "First install $tool $info"
> +		exit 1
> +	fi
> +done || exit 1
> +
> +echo
> +echo "============================================================"
> +echo "========== Compiling U-Boot for Nokia RX-51 board =========="
> +echo "============================================================"
> +echo
> +
> +# First compile u-boot.bin binary for Nokia RX-51 board
> +make nokia_rx51_config
> +make -j4 u-boot.bin ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> +
> +# And then do all stuff in temporary directory
> +mkdir -p nokia_rx51_tmp
> +cd nokia_rx51_tmp
> +
> +test -f mkimage || ln -s ../tools/mkimage .
> +test -f u-boot.bin || ln -s ../u-boot.bin .
> +
> +echo
> +echo "=========================================================================="
> +echo "========== Downloading and compiling qemu from qemu-linaro fork =========="
> +echo "=========================================================================="
> +echo
> +
> +# Download and compile linaro version qemu which has support for n900 machine
> +# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> +if ! test -f qemu-system-arm; then
> +	test -d qemu-linaro || git clone https://git.linaro.org/qemu/qemu-linaro.git
> +	cd qemu-linaro
> +	git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
> +	./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list= --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
> +	make -j4
> +	cd ..
> +	ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
> +fi
> +
> +echo
> +echo "==================================================="
> +echo "========== Downloading external binaries =========="
> +echo "==================================================="
> +echo
> +
> +# Download qflasher and nolo images
> +# This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution
> +wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
> +tar -xf qemu-n900.tar.gz
> +
> +# Download Maemo script u-boot-gen-combined
> +if ! test -f u-boot-gen-combined; then
> +	test -d u-boot-maemo || git clone https://github.com/pali/u-boot-maemo.git
> +	chmod +x u-boot-maemo/debian/u-boot-gen-combined
> +	ln -s u-boot-maemo/debian/u-boot-gen-combined .
> +fi
> +
> +# Download Maemo fiasco kernel
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
> +dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
> +
> +# Download Maemo libc
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
> +dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
> +
> +# Download Maemo busybox
> +wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
> +dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
> +
> +echo
> +echo "======================================="
> +echo "========== Generating images =========="
> +echo "======================================="
> +echo
> +
> +# Generate rootfs directory
> +mkdir -p rootfs
> +mkdir -p rootfs/dev/
> +mkdir -p rootfs/bin/
> +mkdir -p rootfs/sbin/
> +mkdir -p rootfs/lib/
> +cp -a busybox_1.10.2/bin/busybox rootfs/bin/
> +cp -a libc6_2.5.1/lib/ld-linux.so.3 rootfs/lib/
> +cp -a libc6_2.5.1/lib/ld-2.5.so rootfs/lib/
> +cp -a libc6_2.5.1/lib/libc.so.6 rootfs/lib/
> +cp -a libc6_2.5.1/lib/libc-2.5.so rootfs/lib/
> +cp -a libc6_2.5.1/lib/libcrypt.so.1 rootfs/lib/
> +cp -a libc6_2.5.1/lib/libcrypt-2.5.so rootfs/lib/
> +test -f rootfs/bin/sh || ln -sf busybox rootfs/bin/sh
> +test -f rootfs/sbin/poweroff || ln -sf ../bin/busybox rootfs/sbin/poweroff
> +cat > rootfs/sbin/preinit << EOF
> +#!/bin/sh
> +echo
> +echo "Successfully booted"
> +echo
> +/sbin/poweroff -f
> +EOF
> +chmod +x rootfs/sbin/preinit
> +
> +# Generate ubi config file for ubi rootfs image
> +cat > ubi.ini << EOF
> +[rootfs]
> +mode=ubi
> +image=ubifs.img
> +vol_id=0
> +vol_size=160MiB
> +vol_type=dynamic
> +vol_name=rootfs
> +vol_alignment=1
> +vol_flags=autoresize
> +EOF
> +
> +# Generate ubi rootfs image from rootfs directory
> +# NOTE: Character device on host filesystem can be created only by root
> +#       But we do not need it on host filesystem, just in ubifs image
> +#       So run mknod and mkfs.ubifs commands under fakeroot program
> +#       which via LD_PRELOAD simulate mknod() and stat() functions
> +#       so mkfs.ubifs will see dev/console as character device and
> +#       put it correctly as character device into final ubifs image
> +#       Therefore we can run whole script as non-root nobody user
> +fakeroot sh -c '
> +	rm -f rootfs/dev/console;
> +	mknod rootfs/dev/console c 5 1;
> +	/usr/sbin/mkfs.ubifs -m 2048 -e 129024 -c 2047 -r rootfs ubifs.img;
> +'
> +/usr/sbin/ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi.ini
> +
> +# Generate bootmenu for eMMC booting
> +cat > bootmenu_emmc << EOF
> +setenv bootmenu_0 'uImage-2.6.28-omap1 from eMMC=setenv mmcnum 1; setenv mmcpart 1; setenv mmctype fat; setenv bootargs; setenv setup_omap_atag 1; setenv mmckernfile uImage-2.6.28-omap1; run trymmckernboot';
> +setenv bootmenu_1;
> +setenv bootmenu_delay 1;
> +setenv bootdelay 1;
> +EOF
> +./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_emmc bootmenu_emmc.scr
> +
> +# Generate bootmenu for OneNAND booting
> +cat > bootmenu_nand << EOF
> +setenv bootmenu_0 'uImage-2.6.28-omap1 from OneNAND=mtd read initfs \${kernaddr}; setenv bootargs; setenv setup_omap_atag 1; bootm \${kernaddr}';
> +setenv bootmenu_1;
> +setenv bootmenu_delay 1;
> +setenv bootdelay 1;
> +EOF
> +./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_nand bootmenu_nand.scr
> +
> +# Generate combined image from u-boot and Maemo fiasco kernel
> +dd if=kernel_2.6.28/boot/zImage-2.6.28-20103103+0m5.fiasco of=zImage-2.6.28-omap1 skip=95 bs=1
> +./mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage-2.6.28-omap1 -d zImage-2.6.28-omap1 uImage-2.6.28-omap1
> +./u-boot-gen-combined u-boot.bin uImage-2.6.28-omap1 combined.bin
> +
> +# Generate combined hack image from u-boot and Maemo fiasco kernel (kernel starts at 2MB offset and qflasher puts 2kB header before supplied image)
> +cp u-boot.bin combined_hack.bin
> +dd if=uImage-2.6.28-omap1 of=combined_hack.bin bs=1024 seek=$((2048-2))
> +
> +# Generate FAT32 eMMC image for eMMC booting
> +truncate -s 50MiB emmc_emmc.img
> +mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_emmc.img
> +mcopy uImage-2.6.28-omap1 ::/uImage-2.6.28-omap1 -i emmc_emmc.img
> +mcopy bootmenu_emmc.scr ::/bootmenu.scr -i emmc_emmc.img
> +
> +# Generate FAT32 eMMC image for OneNAND booting
> +truncate -s 50MiB emmc_nand.img
> +mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_nand.img
> +mcopy bootmenu_nand.scr ::/bootmenu.scr -i emmc_nand.img
> +
> +# Generate MTD image for RAM booting from bootloader nolo images, compiled image and rootfs image
> +rm -f mtd_ram.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined.bin -r ubi.img -m rx51 -o mtd_ram.img
> +
> +# Generate MTD image for eMMC booting from bootloader nolo images, u-boot image and rootfs image
> +rm -f mtd_emmc.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -r ubi.img -m rx51 -o mtd_emmc.img
> +
> +# Generate MTD image for OneNAND booting from bootloader nolo images, combined hacked image and rootfs image
> +# Kernel image is put into initfs area, but qflasher reject to copy kernel image into initfs area because it does not have initfs signature
> +# This is hack to workaround this problem, tell qflasher that kernel area for u-boot is bigger and put big combined hacked image (u-boot + kernel with correct offset)
> +rm -f mtd_nand.img
> +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined_hack.bin -r ubi.img -m rx51 -p k=4094,i=2 -o mtd_nand.img
> +
> +echo
> +echo "======================================================"
> +echo "========== Running test images in n900 qemu =========="
> +echo "======================================================"
> +echo
> +
> +# Run MTD image in qemu and wait for 300s if kernel from RAM is correctly booted
> +rm -f qemu_ram.log
> +./qemu-system-arm -M n900 -mtdblock mtd_ram.img -serial /dev/stdout -display none > qemu_ram.log &
> +qemu_pid=$!
> +tail -F qemu_ram.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +# Run MTD image in qemu and wait for 300s if kernel from eMMC is correctly booted
> +rm -f qemu_emmc.log
> +./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial /dev/stdout -display none > qemu_emmc.log &
> +qemu_pid=$!
> +tail -F qemu_emmc.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +# Run MTD image in qemu and wait for 300s if kernel from OneNAND is correctly booted
> +rm -f qemu_nand.log
> +./qemu-system-arm -M n900 -mtdblock mtd_nand.img -sd emmc_nand.img -serial /dev/stdout -display none > qemu_nand.log &
> +qemu_pid=$!
> +tail -F qemu_nand.log &
> +tail_pid=$!
> +{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
> +sleep_pid=$!
> +wait $qemu_pid || true
> +kill -9 $tail_pid $sleep_pid 2>/dev/null || true
> +
> +echo
> +echo "============================="
> +echo "========== Results =========="
> +echo "============================="
> +echo
> +
> +if grep -q 'Successfully booted' qemu_ram.log; then echo "Kernel was successfully booted from RAM"; else echo "Failed to boot kernel from RAM"; fi
> +if grep -q 'Successfully booted' qemu_emmc.log; then echo "Kernel was successfully booted from eMMC"; else echo "Failed to boot kernel from eMMC"; fi
> +if grep -q 'Successfully booted' qemu_nand.log; then echo "Kernel was successfully booted from OneNAND"; else echo "Failed to boot kernel from OneNAND"; fi
> +
> +echo
> +
> +if grep -q 'Successfully booted' qemu_ram.log && grep -q 'Successfully booted' qemu_emmc.log && grep -q 'Successfully booted' qemu_nand.log; then
> +	echo "All tests passed"
> +	exit 0
> +else
> +	echo "Some tests failed"
> +	exit 1
> +fi
> -- 
> 2.20.1
> 

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Sat, Apr 25, 2020 at 11:00:06AM +0200, Pali Roh?r wrote:
> This patch contains test/nokia_rx51_test.sh script which automatically
> download and compile all needed tools in local temporary directory to
> generate a simple MTD images for booting Maemo kernel image by U-Boot from
> RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
> provided by qemu-linaro project.
> 
> This script does not need any special privileges, so it can be run as
> non-root nobody user.
> 
> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> successfully booted in emulator.
> 
> Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
> .travis.yml so it would be automatically run on those CI services.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>
> ---
> Changes in v2:
> * Fix apt dependences for Travis CI
> * Move definition of Travis job into own section
> * Add definition for Azure and Gitlab CI services
> * Add script to MAINTAINERS file
> * Build U-Boot binary in test script too
> * Show error message when some dependency for script is missing
> * Fix addresses for booting kernel from OneNAND
> * Do all stuff in nokia_rx51_tmp temporary directory
> * Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
>   (instead of mkfs.fat from dosfstools with custom patches)
> * Show more verbose log messages
> * Do not use sudo, instead run parts of script under fakeroot
>   (fakeroot just run binary with own LD_PRELOAD library which emulates
>    mknod() function for later usage by stat() function)
> * So script can be now run as non-root nobody user and it put all stuff
>   in nokia_rx51_tmp temporary directory, so can be run locally without
>   any issue.
> ---
>  .azure-pipelines.yml         |   7 +
>  .gitlab-ci.yml               |   6 +
>  .travis.yml                  |   7 +
>  board/nokia/rx51/MAINTAINERS |   1 +
>  test/nokia_rx51_test.sh      | 262 +++++++++++++++++++++++++++++++++++
>  5 files changed, 283 insertions(+)
>  create mode 100755 test/nokia_rx51_test.sh
> 
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index d3e7b4dd02..a812f7f906 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -151,6 +151,13 @@ jobs:
>            # seems to hang forever with pre-configured "container" environment
>            docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh
>  
> +  - job: nokia_rx51_test
> +    displayName: 'Run tests for Nokia RX-51 (aka N900)'
> +    pool:
> +      vmImage: $(ubuntu_vm)
> +    steps:
> +      - script: test/nokia_rx51_test.sh
> +
>    - job: test_py
>      displayName: 'test.py'
>      pool:
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 08bdf81e74..678f4323a0 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -170,6 +170,12 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
>        ./tools/patman/patman --test;
>        make testconfig
>  
> +Run tests for Nokia RX-51 (aka N900):
> +  tags: [ 'all' ]
> +  stage: testsuites
> +  script:
> +    - test/nokia_rx51_test.sh
> +
>  # Test sandbox with test.py
>  sandbox test.py:
>    tags: [ 'all' ]
> diff --git a/.travis.yml b/.travis.yml
> index 82e3b91523..b32555d89f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -49,6 +49,8 @@ addons:
>      - mtools
>      - openssl
>      - sbsigntool
> +    - fakeroot
> +    - mtd-utils

So the Docker container for Azure/GitLab will need an update too.  I'll
take care of that shortly.  Otherwise:

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200427/0ac37bc8/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> On Sat, Apr 25, 2020 at 11:00:06AM +0200, Pali Roh?r wrote:
> > This patch contains test/nokia_rx51_test.sh script which automatically
> > download and compile all needed tools in local temporary directory to
> > generate a simple MTD images for booting Maemo kernel image by U-Boot from
> > RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
> > provided by qemu-linaro project.
> > 
> > This script does not need any special privileges, so it can be run as
> > non-root nobody user.
> > 
> > It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > successfully booted in emulator.
> > 
> > Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
> > .travis.yml so it would be automatically run on those CI services.
> > 
> > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > ---
> > Changes in v2:
> > * Fix apt dependences for Travis CI
> > * Move definition of Travis job into own section
> > * Add definition for Azure and Gitlab CI services
> > * Add script to MAINTAINERS file
> > * Build U-Boot binary in test script too
> > * Show error message when some dependency for script is missing
> > * Fix addresses for booting kernel from OneNAND
> > * Do all stuff in nokia_rx51_tmp temporary directory
> > * Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
> >   (instead of mkfs.fat from dosfstools with custom patches)
> > * Show more verbose log messages
> > * Do not use sudo, instead run parts of script under fakeroot
> >   (fakeroot just run binary with own LD_PRELOAD library which emulates
> >    mknod() function for later usage by stat() function)
> > * So script can be now run as non-root nobody user and it put all stuff
> >   in nokia_rx51_tmp temporary directory, so can be run locally without
> >   any issue.
> > ---
> >  .azure-pipelines.yml         |   7 +
> >  .gitlab-ci.yml               |   6 +
> >  .travis.yml                  |   7 +
> >  board/nokia/rx51/MAINTAINERS |   1 +
> >  test/nokia_rx51_test.sh      | 262 +++++++++++++++++++++++++++++++++++
> >  5 files changed, 283 insertions(+)
> >  create mode 100755 test/nokia_rx51_test.sh
> > 
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index d3e7b4dd02..a812f7f906 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -151,6 +151,13 @@ jobs:
> >            # seems to hang forever with pre-configured "container" environment
> >            docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh
> >  
> > +  - job: nokia_rx51_test
> > +    displayName: 'Run tests for Nokia RX-51 (aka N900)'
> > +    pool:
> > +      vmImage: $(ubuntu_vm)
> > +    steps:
> > +      - script: test/nokia_rx51_test.sh
> > +
> >    - job: test_py
> >      displayName: 'test.py'
> >      pool:
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 08bdf81e74..678f4323a0 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -170,6 +170,12 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
> >        ./tools/patman/patman --test;
> >        make testconfig
> >  
> > +Run tests for Nokia RX-51 (aka N900):
> > +  tags: [ 'all' ]
> > +  stage: testsuites
> > +  script:
> > +    - test/nokia_rx51_test.sh
> > +
> >  # Test sandbox with test.py
> >  sandbox test.py:
> >    tags: [ 'all' ]
> > diff --git a/.travis.yml b/.travis.yml
> > index 82e3b91523..b32555d89f 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -49,6 +49,8 @@ addons:
> >      - mtools
> >      - openssl
> >      - sbsigntool
> > +    - fakeroot
> > +    - mtd-utils
> 
> So the Docker container for Azure/GitLab will need an update too.

Do not forget to put arm-linux-gnueabi-gcc into PATH for rx51 test script.

> I'll take care of that shortly.  Otherwise:
> 
> Reviewed-by: Tom Rini <trini@konsulko.com>

Ok, thank you!

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > I'll take care of that shortly.  Otherwise:
> > 
> > Reviewed-by: Tom Rini <trini@konsulko.com>
> 
> Ok, thank you!

Hello Tom! Will you take whole patch series? Or is there anything else
needed to be done from my side for this N900 patch series?

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > I'll take care of that shortly.  Otherwise:
> > > 
> > > Reviewed-by: Tom Rini <trini@konsulko.com>
> > 
> > Ok, thank you!
> 
> Hello Tom! Will you take whole patch series? Or is there anything else
> needed to be done from my side for this N900 patch series?

Lokesh is the custodian for the TI tree these days, so whenever it's in
his next PR.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200508/d6d64636/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Lokesh Vutla]

On 08/05/20 6:40 PM, Tom Rini wrote:
> On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
>> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
>>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
>>>> I'll take care of that shortly.  Otherwise:
>>>>
>>>> Reviewed-by: Tom Rini <trini@konsulko.com>
>>>
>>> Ok, thank you!
>>
>> Hello Tom! Will you take whole patch series? Or is there anything else
>> needed to be done from my side for this N900 patch series?
> 
> Lokesh is the custodian for the TI tree these days, so whenever it's in
> his next PR.  Thanks!
> 

I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
changed?

[0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228

Thanks and regards,
Lokesh

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> On 08/05/20 6:40 PM, Tom Rini wrote:
> > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> >>>> I'll take care of that shortly.  Otherwise:
> >>>>
> >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> >>>
> >>> Ok, thank you!
> >>
> >> Hello Tom! Will you take whole patch series? Or is there anything else
> >> needed to be done from my side for this N900 patch series?
> > 
> > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > his next PR.  Thanks!
> > 
> 
> I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> changed?
> 
> [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228

Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.

I figured out that on Travis it is available in ~/.buildman-toolchains
but not exported to $PATH. So for Travis build I added...

export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH

... as can be seen in the last patch.

Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
Maybe Tom knows it as he already wrote that would take care of updating
Gitlab image.

> Thanks and regards,
> Lokesh

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > >>>> I'll take care of that shortly.  Otherwise:
> > >>>>
> > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > >>>
> > >>> Ok, thank you!
> > >>
> > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > >> needed to be done from my side for this N900 patch series?
> > > 
> > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > his next PR.  Thanks!
> > > 
> > 
> > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > changed?
> > 
> > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> 
> Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> 
> I figured out that on Travis it is available in ~/.buildman-toolchains
> but not exported to $PATH. So for Travis build I added...
> 
> export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> 
> ... as can be seen in the last patch.
> 
> Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> Maybe Tom knows it as he already wrote that would take care of updating
> Gitlab image.

All of the buildman-fetched toolchains are always in the same place, so
a similar change to gitlab/azure will fix those.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200509/812055c9/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > >>>> I'll take care of that shortly.  Otherwise:
> > > >>>>
> > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > >>>
> > > >>> Ok, thank you!
> > > >>
> > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > >> needed to be done from my side for this N900 patch series?
> > > > 
> > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > his next PR.  Thanks!
> > > > 
> > > 
> > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > changed?
> > > 
> > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > 
> > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > 
> > I figured out that on Travis it is available in ~/.buildman-toolchains
> > but not exported to $PATH. So for Travis build I added...
> > 
> > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > 
> > ... as can be seen in the last patch.
> > 
> > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > Maybe Tom knows it as he already wrote that would take care of updating
> > Gitlab image.
> 
> All of the buildman-fetched toolchains are always in the same place, so
> a similar change to gitlab/azure will fix those.  Thanks!

I see that all patches except this one were merged, thanks.

Tom, are you going to take look at this last patch?

It already passed on travis [1] [2] but I do not have those gitlab and
azure accounts to trigger their jobs. But I think that only correct
$PATH is needed for azure and gitlab.

[1] - https://github.com/u-boot/u-boot/pull/30
[2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > >>>>
> > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > >>>
> > > > >>> Ok, thank you!
> > > > >>
> > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > >> needed to be done from my side for this N900 patch series?
> > > > > 
> > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > his next PR.  Thanks!
> > > > > 
> > > > 
> > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > changed?
> > > > 
> > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > 
> > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > 
> > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > but not exported to $PATH. So for Travis build I added...
> > > 
> > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > 
> > > ... as can be seen in the last patch.
> > > 
> > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > Maybe Tom knows it as he already wrote that would take care of updating
> > > Gitlab image.
> > 
> > All of the buildman-fetched toolchains are always in the same place, so
> > a similar change to gitlab/azure will fix those.  Thanks!
> 
> I see that all patches except this one were merged, thanks.
> 
> Tom, are you going to take look at this last patch?
> 
> It already passed on travis [1] [2] but I do not have those gitlab and
> azure accounts to trigger their jobs. But I think that only correct
> $PATH is needed for azure and gitlab.
> 
> [1] - https://github.com/u-boot/u-boot/pull/30
> [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986

No, I've been waiting for you to make an attempt at fixing the jobs.
Anyone can get Azure running and there's enough examples to make a
reasonable attempt at making it work without testing.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200514/17d87f7d/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > >>>>
> > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > >>>
> > > > > >>> Ok, thank you!
> > > > > >>
> > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > 
> > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > his next PR.  Thanks!
> > > > > > 
> > > > > 
> > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > changed?
> > > > > 
> > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > 
> > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > 
> > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > but not exported to $PATH. So for Travis build I added...
> > > > 
> > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > 
> > > > ... as can be seen in the last patch.
> > > > 
> > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > Gitlab image.
> > > 
> > > All of the buildman-fetched toolchains are always in the same place, so
> > > a similar change to gitlab/azure will fix those.  Thanks!
> > 
> > I see that all patches except this one were merged, thanks.
> > 
> > Tom, are you going to take look at this last patch?
> > 
> > It already passed on travis [1] [2] but I do not have those gitlab and
> > azure accounts to trigger their jobs. But I think that only correct
> > $PATH is needed for azure and gitlab.
> > 
> > [1] - https://github.com/u-boot/u-boot/pull/30
> > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> 
> No, I've been waiting for you to make an attempt at fixing the jobs.
> Anyone can get Azure running and there's enough examples to make a
> reasonable attempt at making it work without testing.

So can you give me pointers how to run it?

And is there something more needed for travis job?

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > >>>>
> > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > >>>
> > > > > > >>> Ok, thank you!
> > > > > > >>
> > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > 
> > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > his next PR.  Thanks!
> > > > > > > 
> > > > > > 
> > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > changed?
> > > > > > 
> > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > 
> > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > 
> > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > but not exported to $PATH. So for Travis build I added...
> > > > > 
> > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > 
> > > > > ... as can be seen in the last patch.
> > > > > 
> > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > Gitlab image.
> > > > 
> > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > 
> > > I see that all patches except this one were merged, thanks.
> > > 
> > > Tom, are you going to take look at this last patch?
> > > 
> > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > azure accounts to trigger their jobs. But I think that only correct
> > > $PATH is needed for azure and gitlab.
> > > 
> > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > 
> > No, I've been waiting for you to make an attempt at fixing the jobs.
> > Anyone can get Azure running and there's enough examples to make a
> > reasonable attempt at making it work without testing.
> 
> So can you give me pointers how to run it?

It's a well documented public service.  The only slight trick is you
need to point it at .azure-pipeline.yml and not whatever the default
non-dotfile name is.

> And is there something more needed for travis job?

All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
Since Azure/GitLab share the same docker image (which sadly I don't see
how to make Travis also do), that's why fixing Azure should let you see
what to drop in for GitLab.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200515/b672d920/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > >>>>
> > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > >>>
> > > > > > > >>> Ok, thank you!
> > > > > > > >>
> > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > 
> > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > his next PR.  Thanks!
> > > > > > > > 
> > > > > > > 
> > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > changed?
> > > > > > > 
> > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > 
> > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > 
> > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > 
> > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > 
> > > > > > ... as can be seen in the last patch.
> > > > > > 
> > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > Gitlab image.
> > > > > 
> > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > 
> > > > I see that all patches except this one were merged, thanks.
> > > > 
> > > > Tom, are you going to take look at this last patch?
> > > > 
> > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > azure accounts to trigger their jobs. But I think that only correct
> > > > $PATH is needed for azure and gitlab.
> > > > 
> > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > 
> > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > Anyone can get Azure running and there's enough examples to make a
> > > reasonable attempt at making it work without testing.
> > 
> > So can you give me pointers how to run it?
> 
> It's a well documented public service.  The only slight trick is you
> need to point it at .azure-pipeline.yml and not whatever the default
> non-dotfile name is.

Tom, sorry, but I grepped whole u-boot source code repository and I did
not find any documentation nor README nor any other information how to
run / extend or modify this service. That is why I asked for some
information... e.g. how I can I run it and check if it is working or
not.

> > And is there something more needed for travis job?
> 
> All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> Since Azure/GitLab share the same docker image (which sadly I don't see
> how to make Travis also do), that's why fixing Azure should let you see
> what to drop in for GitLab.

I prepared this N900 Travis setup for your request [1] and I do not like
to see it thrown away, just because there is unrelated issue on Azure.

I have used Travis before, so I know that opening pull request on github
triggers Travis build and Github directly shows me links to result.

But whatever I did, I was not able to trigger that azure from github
pull request.

[1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > >>>>
> > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > >>>
> > > > > > > > >>> Ok, thank you!
> > > > > > > > >>
> > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > 
> > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > his next PR.  Thanks!
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > changed?
> > > > > > > > 
> > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > 
> > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > 
> > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > 
> > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > 
> > > > > > > ... as can be seen in the last patch.
> > > > > > > 
> > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > Gitlab image.
> > > > > > 
> > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > 
> > > > > I see that all patches except this one were merged, thanks.
> > > > > 
> > > > > Tom, are you going to take look at this last patch?
> > > > > 
> > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > $PATH is needed for azure and gitlab.
> > > > > 
> > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > 
> > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > Anyone can get Azure running and there's enough examples to make a
> > > > reasonable attempt at making it work without testing.
> > > 
> > > So can you give me pointers how to run it?
> > 
> > It's a well documented public service.  The only slight trick is you
> > need to point it at .azure-pipeline.yml and not whatever the default
> > non-dotfile name is.
> 
> Tom, sorry, but I grepped whole u-boot source code repository and I did
> not find any documentation nor README nor any other information how to
> run / extend or modify this service. That is why I asked for some
> information... e.g. how I can I run it and check if it is working or
> not.
> 
> > > And is there something more needed for travis job?
> > 
> > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > Since Azure/GitLab share the same docker image (which sadly I don't see
> > how to make Travis also do), that's why fixing Azure should let you see
> > what to drop in for GitLab.
> 
> I prepared this N900 Travis setup for your request [1] and I do not like
> to see it thrown away, just because there is unrelated issue on Azure.
> 
> I have used Travis before, so I know that opening pull request on github
> triggers Travis build and Github directly shows me links to result.
> 
> But whatever I did, I was not able to trigger that azure from github
> pull request.
> 
> [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html

Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
plugs in to GitHub just as easy as Travis does, but runs quicker.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200515/e14aad1c/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > >>>>
> > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > >>>
> > > > > > > > > >>> Ok, thank you!
> > > > > > > > > >>
> > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > 
> > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > changed?
> > > > > > > > > 
> > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > 
> > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > 
> > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > 
> > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > 
> > > > > > > > ... as can be seen in the last patch.
> > > > > > > > 
> > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > Gitlab image.
> > > > > > > 
> > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > 
> > > > > > I see that all patches except this one were merged, thanks.
> > > > > > 
> > > > > > Tom, are you going to take look at this last patch?
> > > > > > 
> > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > $PATH is needed for azure and gitlab.
> > > > > > 
> > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > 
> > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > reasonable attempt at making it work without testing.
> > > > 
> > > > So can you give me pointers how to run it?
> > > 
> > > It's a well documented public service.  The only slight trick is you
> > > need to point it at .azure-pipeline.yml and not whatever the default
> > > non-dotfile name is.
> > 
> > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > not find any documentation nor README nor any other information how to
> > run / extend or modify this service. That is why I asked for some
> > information... e.g. how I can I run it and check if it is working or
> > not.
> > 
> > > > And is there something more needed for travis job?
> > > 
> > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > how to make Travis also do), that's why fixing Azure should let you see
> > > what to drop in for GitLab.
> > 
> > I prepared this N900 Travis setup for your request [1] and I do not like
> > to see it thrown away, just because there is unrelated issue on Azure.
> > 
> > I have used Travis before, so I know that opening pull request on github
> > triggers Travis build and Github directly shows me links to result.
> > 
> > But whatever I did, I was not able to trigger that azure from github
> > pull request.
> > 
> > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> 
> Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> plugs in to GitHub just as easy as Travis does, but runs quicker.

So seems it is buggy, it was not triggered, see that only Travis was
triggered in pull request: https://github.com/u-boot/u-boot/pull/30

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > >>
> > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > 
> > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > changed?
> > > > > > > > > > 
> > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > 
> > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > 
> > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > 
> > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > 
> > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > 
> > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > Gitlab image.
> > > > > > > > 
> > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > 
> > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > 
> > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > 
> > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > 
> > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > 
> > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > reasonable attempt at making it work without testing.
> > > > > 
> > > > > So can you give me pointers how to run it?
> > > > 
> > > > It's a well documented public service.  The only slight trick is you
> > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > non-dotfile name is.
> > > 
> > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > not find any documentation nor README nor any other information how to
> > > run / extend or modify this service. That is why I asked for some
> > > information... e.g. how I can I run it and check if it is working or
> > > not.
> > > 
> > > > > And is there something more needed for travis job?
> > > > 
> > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > what to drop in for GitLab.
> > > 
> > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > to see it thrown away, just because there is unrelated issue on Azure.
> > > 
> > > I have used Travis before, so I know that opening pull request on github
> > > triggers Travis build and Github directly shows me links to result.
> > > 
> > > But whatever I did, I was not able to trigger that azure from github
> > > pull request.
> > > 
> > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > 
> > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > plugs in to GitHub just as easy as Travis does, but runs quicker.
> 
> So seems it is buggy, it was not triggered, see that only Travis was
> triggered in pull request: https://github.com/u-boot/u-boot/pull/30

Did you configure your Azure account?  If you've used Travis elsewhere
that's why U-Boot just runs there.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200515/5325da73/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Friday 15 May 2020 09:53:23 Tom Rini wrote:
> On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> > On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > > 
> > > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > > changed?
> > > > > > > > > > > 
> > > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > > 
> > > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > > 
> > > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > > 
> > > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > > 
> > > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > > 
> > > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > > Gitlab image.
> > > > > > > > > 
> > > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > > 
> > > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > > 
> > > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > > 
> > > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > > 
> > > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > > 
> > > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > > reasonable attempt at making it work without testing.
> > > > > > 
> > > > > > So can you give me pointers how to run it?
> > > > > 
> > > > > It's a well documented public service.  The only slight trick is you
> > > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > > non-dotfile name is.
> > > > 
> > > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > > not find any documentation nor README nor any other information how to
> > > > run / extend or modify this service. That is why I asked for some
> > > > information... e.g. how I can I run it and check if it is working or
> > > > not.
> > > > 
> > > > > > And is there something more needed for travis job?
> > > > > 
> > > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > > what to drop in for GitLab.
> > > > 
> > > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > > to see it thrown away, just because there is unrelated issue on Azure.
> > > > 
> > > > I have used Travis before, so I know that opening pull request on github
> > > > triggers Travis build and Github directly shows me links to result.
> > > > 
> > > > But whatever I did, I was not able to trigger that azure from github
> > > > pull request.
> > > > 
> > > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > > 
> > > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > > plugs in to GitHub just as easy as Travis does, but runs quicker.
> > 
> > So seems it is buggy, it was not triggered, see that only Travis was
> > triggered in pull request: https://github.com/u-boot/u-boot/pull/30
> 
> Did you configure your Azure account?  If you've used Travis elsewhere
> that's why U-Boot just runs there.

I do not have any Azure account.

For running Travis I do not need any account. It is enough if repository
owner (probably you?) on github enable Travis for particular github
repository. And then Travis is automatically triggered for every open
pull request (even for those who do not have Travis account).

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 03:58:20PM +0200, Pali Roh?r wrote:
> On Friday 15 May 2020 09:53:23 Tom Rini wrote:
> > On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> > > On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > > > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > > > changed?
> > > > > > > > > > > > 
> > > > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > > > 
> > > > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > > > 
> > > > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > > > 
> > > > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > > > 
> > > > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > > > 
> > > > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > > > Gitlab image.
> > > > > > > > > > 
> > > > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > > > 
> > > > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > > > 
> > > > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > > > 
> > > > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > > > 
> > > > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > > > 
> > > > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > > > reasonable attempt at making it work without testing.
> > > > > > > 
> > > > > > > So can you give me pointers how to run it?
> > > > > > 
> > > > > > It's a well documented public service.  The only slight trick is you
> > > > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > > > non-dotfile name is.
> > > > > 
> > > > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > > > not find any documentation nor README nor any other information how to
> > > > > run / extend or modify this service. That is why I asked for some
> > > > > information... e.g. how I can I run it and check if it is working or
> > > > > not.
> > > > > 
> > > > > > > And is there something more needed for travis job?
> > > > > > 
> > > > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > > > what to drop in for GitLab.
> > > > > 
> > > > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > > > to see it thrown away, just because there is unrelated issue on Azure.
> > > > > 
> > > > > I have used Travis before, so I know that opening pull request on github
> > > > > triggers Travis build and Github directly shows me links to result.
> > > > > 
> > > > > But whatever I did, I was not able to trigger that azure from github
> > > > > pull request.
> > > > > 
> > > > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > > > 
> > > > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > > > plugs in to GitHub just as easy as Travis does, but runs quicker.
> > > 
> > > So seems it is buggy, it was not triggered, see that only Travis was
> > > triggered in pull request: https://github.com/u-boot/u-boot/pull/30
> > 
> > Did you configure your Azure account?  If you've used Travis elsewhere
> > that's why U-Boot just runs there.
> 
> I do not have any Azure account.
> 
> For running Travis I do not need any account. It is enough if repository
> owner (probably you?) on github enable Travis for particular github
> repository. And then Travis is automatically triggered for every open
> pull request (even for those who do not have Travis account).

Oh, interesting.  Since PRs to U-Boot github are ignored I didn't notice
you could get Travis triggered on that.  I've finally hooked "u-boot" in
to Azure as well, rather than just my repository, so a new PR may
trigger a build there.

If however you aren't willing to sign up and configure a project, since
both the Azure and GitLab pipelines are just shell in the relevant
areas, you can probably make an educated guess at what the changes
should be and post them.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200515/1a3d006a/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Friday 15 May 2020 10:16:16 Tom Rini wrote:
> On Fri, May 15, 2020 at 03:58:20PM +0200, Pali Roh?r wrote:
> > On Friday 15 May 2020 09:53:23 Tom Rini wrote:
> > > On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> > > > On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > > > > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > > > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > > > > changed?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > > > > 
> > > > > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > > > > 
> > > > > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > > > > 
> > > > > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > > > > 
> > > > > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > > > > 
> > > > > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > > > > Gitlab image.
> > > > > > > > > > > 
> > > > > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > > > > 
> > > > > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > > > > 
> > > > > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > > > > 
> > > > > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > > > > 
> > > > > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > > > > 
> > > > > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > > > > reasonable attempt at making it work without testing.
> > > > > > > > 
> > > > > > > > So can you give me pointers how to run it?
> > > > > > > 
> > > > > > > It's a well documented public service.  The only slight trick is you
> > > > > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > > > > non-dotfile name is.
> > > > > > 
> > > > > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > > > > not find any documentation nor README nor any other information how to
> > > > > > run / extend or modify this service. That is why I asked for some
> > > > > > information... e.g. how I can I run it and check if it is working or
> > > > > > not.
> > > > > > 
> > > > > > > > And is there something more needed for travis job?
> > > > > > > 
> > > > > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > > > > what to drop in for GitLab.
> > > > > > 
> > > > > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > > > > to see it thrown away, just because there is unrelated issue on Azure.
> > > > > > 
> > > > > > I have used Travis before, so I know that opening pull request on github
> > > > > > triggers Travis build and Github directly shows me links to result.
> > > > > > 
> > > > > > But whatever I did, I was not able to trigger that azure from github
> > > > > > pull request.
> > > > > > 
> > > > > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > > > > 
> > > > > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > > > > plugs in to GitHub just as easy as Travis does, but runs quicker.
> > > > 
> > > > So seems it is buggy, it was not triggered, see that only Travis was
> > > > triggered in pull request: https://github.com/u-boot/u-boot/pull/30
> > > 
> > > Did you configure your Azure account?  If you've used Travis elsewhere
> > > that's why U-Boot just runs there.
> > 
> > I do not have any Azure account.
> > 
> > For running Travis I do not need any account. It is enough if repository
> > owner (probably you?) on github enable Travis for particular github
> > repository. And then Travis is automatically triggered for every open
> > pull request (even for those who do not have Travis account).
> 
> Oh, interesting.  Since PRs to U-Boot github are ignored I didn't notice
> you could get Travis triggered on that.  I've finally hooked "u-boot" in
> to Azure as well, rather than just my repository, so a new PR may
> trigger a build there.

Now I updated pull request on github and Azure build was triggered, thanks!

But job is failing because in your (probably?) runner image is missing
mtools package, see:

https://dev.azure.com/u-boot/u-boot/_build/results?buildId=587&view=logs&j=9a06d2a9-1498-5de0-2a01-be581d48ba67&t=f9a6b761-daa3-500f-4840-65a939c5040d

Could you add mtools, fakeroot and mtd-utils packages into that image?

> If however you aren't willing to sign up and configure a project, since
> both the Azure and GitLab pipelines are just shell in the relevant
> areas, you can probably make an educated guess at what the changes
> should be and post them.  Thanks!
> 
> -- 
> Tom

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Fri, May 15, 2020 at 07:40:25PM +0200, Pali Roh?r wrote:
> On Friday 15 May 2020 10:16:16 Tom Rini wrote:
> > On Fri, May 15, 2020 at 03:58:20PM +0200, Pali Roh?r wrote:
> > > On Friday 15 May 2020 09:53:23 Tom Rini wrote:
> > > > On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> > > > > On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > > > > > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > > > > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > > > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > > > > > changed?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > > > > > Gitlab image.
> > > > > > > > > > > > 
> > > > > > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > > > > > 
> > > > > > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > > > > > 
> > > > > > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > > > > > 
> > > > > > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > > > > > 
> > > > > > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > > > > > 
> > > > > > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > > > > > reasonable attempt at making it work without testing.
> > > > > > > > > 
> > > > > > > > > So can you give me pointers how to run it?
> > > > > > > > 
> > > > > > > > It's a well documented public service.  The only slight trick is you
> > > > > > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > > > > > non-dotfile name is.
> > > > > > > 
> > > > > > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > > > > > not find any documentation nor README nor any other information how to
> > > > > > > run / extend or modify this service. That is why I asked for some
> > > > > > > information... e.g. how I can I run it and check if it is working or
> > > > > > > not.
> > > > > > > 
> > > > > > > > > And is there something more needed for travis job?
> > > > > > > > 
> > > > > > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > > > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > > > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > > > > > what to drop in for GitLab.
> > > > > > > 
> > > > > > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > > > > > to see it thrown away, just because there is unrelated issue on Azure.
> > > > > > > 
> > > > > > > I have used Travis before, so I know that opening pull request on github
> > > > > > > triggers Travis build and Github directly shows me links to result.
> > > > > > > 
> > > > > > > But whatever I did, I was not able to trigger that azure from github
> > > > > > > pull request.
> > > > > > > 
> > > > > > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > > > > > 
> > > > > > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > > > > > plugs in to GitHub just as easy as Travis does, but runs quicker.
> > > > > 
> > > > > So seems it is buggy, it was not triggered, see that only Travis was
> > > > > triggered in pull request: https://github.com/u-boot/u-boot/pull/30
> > > > 
> > > > Did you configure your Azure account?  If you've used Travis elsewhere
> > > > that's why U-Boot just runs there.
> > > 
> > > I do not have any Azure account.
> > > 
> > > For running Travis I do not need any account. It is enough if repository
> > > owner (probably you?) on github enable Travis for particular github
> > > repository. And then Travis is automatically triggered for every open
> > > pull request (even for those who do not have Travis account).
> > 
> > Oh, interesting.  Since PRs to U-Boot github are ignored I didn't notice
> > you could get Travis triggered on that.  I've finally hooked "u-boot" in
> > to Azure as well, rather than just my repository, so a new PR may
> > trigger a build there.
> 
> Now I updated pull request on github and Azure build was triggered, thanks!
> 
> But job is failing because in your (probably?) runner image is missing
> mtools package, see:
> 
> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=587&view=logs&j=9a06d2a9-1498-5de0-2a01-be581d48ba67&t=f9a6b761-daa3-500f-4840-65a939c5040d
> 
> Could you add mtools, fakeroot and mtd-utils packages into that image?

More PATH problems I guess, the Dockerfile is at
https://gitlab.denx.de/u-boot/gitlab-ci-runner/blob/master/Dockerfile
and I put mtools, etc, in last time I updated things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200515/865d5b45/attachment.sig>

[PATCH v2] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Friday 15 May 2020 14:34:55 Tom Rini wrote:
> On Fri, May 15, 2020 at 07:40:25PM +0200, Pali Roh?r wrote:
> > On Friday 15 May 2020 10:16:16 Tom Rini wrote:
> > > On Fri, May 15, 2020 at 03:58:20PM +0200, Pali Roh?r wrote:
> > > > On Friday 15 May 2020 09:53:23 Tom Rini wrote:
> > > > > On Fri, May 15, 2020 at 03:51:22PM +0200, Pali Roh?r wrote:
> > > > > > On Friday 15 May 2020 09:48:48 Tom Rini wrote:
> > > > > > > On Fri, May 15, 2020 at 03:46:02PM +0200, Pali Roh?r wrote:
> > > > > > > > On Friday 15 May 2020 09:20:20 Tom Rini wrote:
> > > > > > > > > On Fri, May 15, 2020 at 09:33:47AM +0200, Pali Roh?r wrote:
> > > > > > > > > > On Thursday 14 May 2020 20:01:19 Tom Rini wrote:
> > > > > > > > > > > On Fri, May 15, 2020 at 12:41:52AM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > On Saturday 09 May 2020 16:56:10 Tom Rini wrote:
> > > > > > > > > > > > > On Sat, May 09, 2020 at 06:35:40PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > > > On Saturday 09 May 2020 21:58:19 Lokesh Vutla wrote:
> > > > > > > > > > > > > > > On 08/05/20 6:40 PM, Tom Rini wrote:
> > > > > > > > > > > > > > > > On Fri, May 08, 2020 at 02:52:55PM +0200, Pali Roh?r wrote:
> > > > > > > > > > > > > > > >> On Tuesday 28 April 2020 09:37:21 Pali Roh?r wrote:
> > > > > > > > > > > > > > > >>> On Monday 27 April 2020 14:00:47 Tom Rini wrote:
> > > > > > > > > > > > > > > >>>> I'll take care of that shortly.  Otherwise:
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> Ok, thank you!
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> Hello Tom! Will you take whole patch series? Or is there anything else
> > > > > > > > > > > > > > > >> needed to be done from my side for this N900 patch series?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Lokesh is the custodian for the TI tree these days, so whenever it's in
> > > > > > > > > > > > > > > > his next PR.  Thanks!
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I see gitlab is failing to build this patch[0]. Does cross compiler needs to be
> > > > > > > > > > > > > > > changed?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > [0] https://gitlab.denx.de/u-boot/custodians/u-boot-ti/-/jobs/91228
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Cross compiler arm-linux-gnueabi-gcc needs to be in $PATH.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I figured out that on Travis it is available in ~/.buildman-toolchains
> > > > > > > > > > > > > > but not exported to $PATH. So for Travis build I added...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ... as can be seen in the last patch.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Do you know where is installed arm-linux-gnueabi toolchain on Gitlab?
> > > > > > > > > > > > > > Maybe Tom knows it as he already wrote that would take care of updating
> > > > > > > > > > > > > > Gitlab image.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > All of the buildman-fetched toolchains are always in the same place, so
> > > > > > > > > > > > > a similar change to gitlab/azure will fix those.  Thanks!
> > > > > > > > > > > > 
> > > > > > > > > > > > I see that all patches except this one were merged, thanks.
> > > > > > > > > > > > 
> > > > > > > > > > > > Tom, are you going to take look at this last patch?
> > > > > > > > > > > > 
> > > > > > > > > > > > It already passed on travis [1] [2] but I do not have those gitlab and
> > > > > > > > > > > > azure accounts to trigger their jobs. But I think that only correct
> > > > > > > > > > > > $PATH is needed for azure and gitlab.
> > > > > > > > > > > > 
> > > > > > > > > > > > [1] - https://github.com/u-boot/u-boot/pull/30
> > > > > > > > > > > > [2] - https://travis-ci.org/github/u-boot/u-boot/jobs/679162986
> > > > > > > > > > > 
> > > > > > > > > > > No, I've been waiting for you to make an attempt at fixing the jobs.
> > > > > > > > > > > Anyone can get Azure running and there's enough examples to make a
> > > > > > > > > > > reasonable attempt at making it work without testing.
> > > > > > > > > > 
> > > > > > > > > > So can you give me pointers how to run it?
> > > > > > > > > 
> > > > > > > > > It's a well documented public service.  The only slight trick is you
> > > > > > > > > need to point it at .azure-pipeline.yml and not whatever the default
> > > > > > > > > non-dotfile name is.
> > > > > > > > 
> > > > > > > > Tom, sorry, but I grepped whole u-boot source code repository and I did
> > > > > > > > not find any documentation nor README nor any other information how to
> > > > > > > > run / extend or modify this service. That is why I asked for some
> > > > > > > > information... e.g. how I can I run it and check if it is working or
> > > > > > > > not.
> > > > > > > > 
> > > > > > > > > > And is there something more needed for travis job?
> > > > > > > > > 
> > > > > > > > > All 3 CIs need to pass, but no, if Travis is passing, that part is fine.
> > > > > > > > > Since Azure/GitLab share the same docker image (which sadly I don't see
> > > > > > > > > how to make Travis also do), that's why fixing Azure should let you see
> > > > > > > > > what to drop in for GitLab.
> > > > > > > > 
> > > > > > > > I prepared this N900 Travis setup for your request [1] and I do not like
> > > > > > > > to see it thrown away, just because there is unrelated issue on Azure.
> > > > > > > > 
> > > > > > > > I have used Travis before, so I know that opening pull request on github
> > > > > > > > triggers Travis build and Github directly shows me links to result.
> > > > > > > > 
> > > > > > > > But whatever I did, I was not able to trigger that azure from github
> > > > > > > > pull request.
> > > > > > > > 
> > > > > > > > [1] - https://lists.denx.de/pipermail/u-boot/2018-December/353019.html
> > > > > > > 
> > > > > > > Sorry, I mean Azure itself is a well documented public SaaS CI tool.  It
> > > > > > > plugs in to GitHub just as easy as Travis does, but runs quicker.
> > > > > > 
> > > > > > So seems it is buggy, it was not triggered, see that only Travis was
> > > > > > triggered in pull request: https://github.com/u-boot/u-boot/pull/30
> > > > > 
> > > > > Did you configure your Azure account?  If you've used Travis elsewhere
> > > > > that's why U-Boot just runs there.
> > > > 
> > > > I do not have any Azure account.
> > > > 
> > > > For running Travis I do not need any account. It is enough if repository
> > > > owner (probably you?) on github enable Travis for particular github
> > > > repository. And then Travis is automatically triggered for every open
> > > > pull request (even for those who do not have Travis account).
> > > 
> > > Oh, interesting.  Since PRs to U-Boot github are ignored I didn't notice
> > > you could get Travis triggered on that.  I've finally hooked "u-boot" in
> > > to Azure as well, rather than just my repository, so a new PR may
> > > trigger a build there.
> > 
> > Now I updated pull request on github and Azure build was triggered, thanks!
> > 
> > But job is failing because in your (probably?) runner image is missing
> > mtools package, see:
> > 
> > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=587&view=logs&j=9a06d2a9-1498-5de0-2a01-be581d48ba67&t=f9a6b761-daa3-500f-4840-65a939c5040d
> > 
> > Could you add mtools, fakeroot and mtd-utils packages into that image?
> 
> More PATH problems I guess, the Dockerfile is at
> https://gitlab.denx.de/u-boot/gitlab-ci-runner/blob/master/Dockerfile
> and I put mtools, etc, in last time I updated things.

Seems that I was able to fix azure job and finally it passed for opened github pull request:
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=592&view=logs&jobId=9a06d2a9-1498-5de0-2a01-be581d48ba67&j=9a06d2a9-1498-5de0-2a01-be581d48ba67&t=f9a6b761-daa3-500f-4840-65a939c5040d

I will sent updated patch which fixes this issue for azure.

[PATCH v3] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

This patch contains test/nokia_rx51_test.sh script which automatically
download and compile all needed tools in local temporary directory to
generate a simple MTD images for booting Maemo kernel image by U-Boot from
RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
provided by qemu-linaro project.

This script does not need any special privileges, so it can be run as
non-root nobody user.

It can be used to check that U-Boot for Nokia N900 is not broken and can be
successfully booted in emulator.

Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
.travis.yml so it would be automatically run on those CI services.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
Changes in v3:
* Fix job for Azure
Changes in v2:
* Fix apt dependences for Travis CI
* Move definition of Travis job into own section
* Add definition for Azure and Gitlab CI services
* Add script to MAINTAINERS file
* Build U-Boot binary in test script too
* Show error message when some dependency for script is missing
* Fix addresses for booting kernel from OneNAND
* Do all stuff in nokia_rx51_tmp temporary directory
* Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
  (instead of mkfs.fat from dosfstools with custom patches)
* Show more verbose log messages
* Do not use sudo, instead run parts of script under fakeroot
  (fakeroot just run binary with own LD_PRELOAD library which emulates
   mknod() function for later usage by stat() function)
* So script can be now run as non-root nobody user and it put all stuff
  in nokia_rx51_tmp temporary directory, so can be run locally without
  any issue.
---
 .azure-pipelines.yml         |  13 ++
 .gitlab-ci.yml               |   8 ++
 .travis.yml                  |   7 +
 board/nokia/rx51/MAINTAINERS |   1 +
 test/nokia_rx51_test.sh      | 262 +++++++++++++++++++++++++++++++++++
 5 files changed, 291 insertions(+)
 create mode 100755 test/nokia_rx51_test.sh

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 5d9645451d..88438e77a1 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -151,6 +151,19 @@ jobs:
           # seems to hang forever with pre-configured "container" environment
           docker run -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/build.sh
 
+  - job: nokia_rx51_test
+    displayName: 'Run tests for Nokia RX-51 (aka N900)'
+    pool:
+      vmImage: $(ubuntu_vm)
+    container:
+      image: $(ci_runner_image)
+      options: $(container_option)
+    steps:
+      - script: |
+          ./tools/buildman/buildman --fetch-arch arm
+          export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
+          test/nokia_rx51_test.sh
+
   - job: test_py
     displayName: 'test.py'
     pool:
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index beaf9b9042..badfcb4254 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -170,6 +170,14 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
       ./tools/patman/patman --test;
       make testconfig
 
+Run tests for Nokia RX-51 (aka N900):
+  tags: [ 'all' ]
+  stage: testsuites
+  script:
+    - ./tools/buildman/buildman --fetch-arch arm;
+      export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH;
+      test/nokia_rx51_test.sh
+
 # Test sandbox with test.py
 sandbox test.py:
   tags: [ 'all' ]
diff --git a/.travis.yml b/.travis.yml
index fbfaaaff25..bb02b6d816 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -50,6 +50,8 @@ addons:
     - mtools
     - openssl
     - sbsigntool
+    - fakeroot
+    - mtd-utils
 
 install:
  # Clone uboot-test-hooks
@@ -492,6 +494,11 @@ matrix:
       script:
         - make tools-only_config envtools -j$(nproc)
 
+    - name: "Run tests for Nokia RX-51 (aka N900)"
+      script:
+        - export PATH=~/.buildman-toolchains/gcc-9.2.0-nolibc/arm-linux-gnueabi/bin/:$PATH
+        - test/nokia_rx51_test.sh
+
     # test/py
     - name: "test/py sandbox"
       env:
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index f2a712620b..58b16bf9a9 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -5,3 +5,4 @@ F:	board/nokia/rx51/
 F:	include/configs/nokia_rx51.h
 F:	configs/nokia_rx51_defconfig
 F:	doc/README.nokia_rx51
+F:	test/nokia_rx51_test.sh
diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh
new file mode 100755
index 0000000000..b17542b8c1
--- /dev/null
+++ b/test/nokia_rx51_test.sh
@@ -0,0 +1,262 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: GPL-2.0+
+# (C) 2020 Pali Roh?r <pali@kernel.org>
+
+# External tools needed for this test:
+echo '
+	wget
+	git
+	truncate
+	tar
+	dpkg
+	dd
+	make
+	gcc
+	arm-linux-gnueabi-gcc
+	fakeroot		(homepage http://fakeroot-ng.lingnu.com/)
+	mcopy			(from mtools, homepage http://www.gnu.org/software/mtools/)
+	mformat			(from mtools, homepage http://www.gnu.org/software/mtools/)
+	/usr/sbin/mkfs.ubifs	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
+	/usr/sbin/ubinize	(from mtd-utils, homepage http://www.linux-mtd.infradead.org/)
+' | while read tool info; do
+	if test -z "$tool"; then continue; fi
+	if ! which $tool 1>/dev/null 2>&1; then
+		echo "Tool $tool was not found and is required to run this test"
+		echo "First install $tool $info"
+		exit 1
+	fi
+done || exit 1
+
+echo
+echo "============================================================"
+echo "========== Compiling U-Boot for Nokia RX-51 board =========="
+echo "============================================================"
+echo
+
+# First compile u-boot.bin binary for Nokia RX-51 board
+make nokia_rx51_config
+make -j4 u-boot.bin ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
+
+# And then do all stuff in temporary directory
+mkdir -p nokia_rx51_tmp
+cd nokia_rx51_tmp
+
+test -f mkimage || ln -s ../tools/mkimage .
+test -f u-boot.bin || ln -s ../u-boot.bin .
+
+echo
+echo "=========================================================================="
+echo "========== Downloading and compiling qemu from qemu-linaro fork =========="
+echo "=========================================================================="
+echo
+
+# Download and compile linaro version qemu which has support for n900 machine
+# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+if ! test -f qemu-system-arm; then
+	test -d qemu-linaro || git clone https://git.linaro.org/qemu/qemu-linaro.git
+	cd qemu-linaro
+	git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+	./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list= --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
+	make -j4
+	cd ..
+	ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
+fi
+
+echo
+echo "==================================================="
+echo "========== Downloading external binaries =========="
+echo "==================================================="
+echo
+
+# Download qflasher and nolo images
+# This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution
+wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
+tar -xf qemu-n900.tar.gz
+
+# Download Maemo script u-boot-gen-combined
+if ! test -f u-boot-gen-combined; then
+	test -d u-boot-maemo || git clone https://github.com/pali/u-boot-maemo.git
+	chmod +x u-boot-maemo/debian/u-boot-gen-combined
+	ln -s u-boot-maemo/debian/u-boot-gen-combined .
+fi
+
+# Download Maemo fiasco kernel
+wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
+
+# Download Maemo libc
+wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
+dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
+
+# Download Maemo busybox
+wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
+dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
+
+echo
+echo "======================================="
+echo "========== Generating images =========="
+echo "======================================="
+echo
+
+# Generate rootfs directory
+mkdir -p rootfs
+mkdir -p rootfs/dev/
+mkdir -p rootfs/bin/
+mkdir -p rootfs/sbin/
+mkdir -p rootfs/lib/
+cp -a busybox_1.10.2/bin/busybox rootfs/bin/
+cp -a libc6_2.5.1/lib/ld-linux.so.3 rootfs/lib/
+cp -a libc6_2.5.1/lib/ld-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libc.so.6 rootfs/lib/
+cp -a libc6_2.5.1/lib/libc-2.5.so rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt.so.1 rootfs/lib/
+cp -a libc6_2.5.1/lib/libcrypt-2.5.so rootfs/lib/
+test -f rootfs/bin/sh || ln -sf busybox rootfs/bin/sh
+test -f rootfs/sbin/poweroff || ln -sf ../bin/busybox rootfs/sbin/poweroff
+cat > rootfs/sbin/preinit << EOF
+#!/bin/sh
+echo
+echo "Successfully booted"
+echo
+/sbin/poweroff -f
+EOF
+chmod +x rootfs/sbin/preinit
+
+# Generate ubi config file for ubi rootfs image
+cat > ubi.ini << EOF
+[rootfs]
+mode=ubi
+image=ubifs.img
+vol_id=0
+vol_size=160MiB
+vol_type=dynamic
+vol_name=rootfs
+vol_alignment=1
+vol_flags=autoresize
+EOF
+
+# Generate ubi rootfs image from rootfs directory
+# NOTE: Character device on host filesystem can be created only by root
+#       But we do not need it on host filesystem, just in ubifs image
+#       So run mknod and mkfs.ubifs commands under fakeroot program
+#       which via LD_PRELOAD simulate mknod() and stat() functions
+#       so mkfs.ubifs will see dev/console as character device and
+#       put it correctly as character device into final ubifs image
+#       Therefore we can run whole script as non-root nobody user
+fakeroot sh -c '
+	rm -f rootfs/dev/console;
+	mknod rootfs/dev/console c 5 1;
+	/usr/sbin/mkfs.ubifs -m 2048 -e 129024 -c 2047 -r rootfs ubifs.img;
+'
+/usr/sbin/ubinize -o ubi.img -p 128KiB -m 2048 -s 512 ubi.ini
+
+# Generate bootmenu for eMMC booting
+cat > bootmenu_emmc << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from eMMC=setenv mmcnum 1; setenv mmcpart 1; setenv mmctype fat; setenv bootargs; setenv setup_omap_atag 1; setenv mmckernfile uImage-2.6.28-omap1; run trymmckernboot';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_emmc bootmenu_emmc.scr
+
+# Generate bootmenu for OneNAND booting
+cat > bootmenu_nand << EOF
+setenv bootmenu_0 'uImage-2.6.28-omap1 from OneNAND=mtd read initfs \${kernaddr}; setenv bootargs; setenv setup_omap_atag 1; bootm \${kernaddr}';
+setenv bootmenu_1;
+setenv bootmenu_delay 1;
+setenv bootdelay 1;
+EOF
+./mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n bootmenu -d bootmenu_nand bootmenu_nand.scr
+
+# Generate combined image from u-boot and Maemo fiasco kernel
+dd if=kernel_2.6.28/boot/zImage-2.6.28-20103103+0m5.fiasco of=zImage-2.6.28-omap1 skip=95 bs=1
+./mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage-2.6.28-omap1 -d zImage-2.6.28-omap1 uImage-2.6.28-omap1
+./u-boot-gen-combined u-boot.bin uImage-2.6.28-omap1 combined.bin
+
+# Generate combined hack image from u-boot and Maemo fiasco kernel (kernel starts@2MB offset and qflasher puts 2kB header before supplied image)
+cp u-boot.bin combined_hack.bin
+dd if=uImage-2.6.28-omap1 of=combined_hack.bin bs=1024 seek=$((2048-2))
+
+# Generate FAT32 eMMC image for eMMC booting
+truncate -s 50MiB emmc_emmc.img
+mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_emmc.img
+mcopy uImage-2.6.28-omap1 ::/uImage-2.6.28-omap1 -i emmc_emmc.img
+mcopy bootmenu_emmc.scr ::/bootmenu.scr -i emmc_emmc.img
+
+# Generate FAT32 eMMC image for OneNAND booting
+truncate -s 50MiB emmc_nand.img
+mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_nand.img
+mcopy bootmenu_nand.scr ::/bootmenu.scr -i emmc_nand.img
+
+# Generate MTD image for RAM booting from bootloader nolo images, compiled image and rootfs image
+rm -f mtd_ram.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined.bin -r ubi.img -m rx51 -o mtd_ram.img
+
+# Generate MTD image for eMMC booting from bootloader nolo images, u-boot image and rootfs image
+rm -f mtd_emmc.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -r ubi.img -m rx51 -o mtd_emmc.img
+
+# Generate MTD image for OneNAND booting from bootloader nolo images, combined hacked image and rootfs image
+# Kernel image is put into initfs area, but qflasher reject to copy kernel image into initfs area because it does not have initfs signature
+# This is hack to workaround this problem, tell qflasher that kernel area for u-boot is bigger and put big combined hacked image (u-boot + kernel with correct offset)
+rm -f mtd_nand.img
+./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k combined_hack.bin -r ubi.img -m rx51 -p k=4094,i=2 -o mtd_nand.img
+
+echo
+echo "======================================================"
+echo "========== Running test images in n900 qemu =========="
+echo "======================================================"
+echo
+
+# Run MTD image in qemu and wait for 300s if kernel from RAM is correctly booted
+rm -f qemu_ram.log
+./qemu-system-arm -M n900 -mtdblock mtd_ram.img -serial /dev/stdout -display none > qemu_ram.log &
+qemu_pid=$!
+tail -F qemu_ram.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from eMMC is correctly booted
+rm -f qemu_emmc.log
+./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial /dev/stdout -display none > qemu_emmc.log &
+qemu_pid=$!
+tail -F qemu_emmc.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+# Run MTD image in qemu and wait for 300s if kernel from OneNAND is correctly booted
+rm -f qemu_nand.log
+./qemu-system-arm -M n900 -mtdblock mtd_nand.img -sd emmc_nand.img -serial /dev/stdout -display none > qemu_nand.log &
+qemu_pid=$!
+tail -F qemu_nand.log &
+tail_pid=$!
+{ sleep 300 || true; kill -9 $qemu_pid $tail_pid 2>/dev/null || true; } &
+sleep_pid=$!
+wait $qemu_pid || true
+kill -9 $tail_pid $sleep_pid 2>/dev/null || true
+
+echo
+echo "============================="
+echo "========== Results =========="
+echo "============================="
+echo
+
+if grep -q 'Successfully booted' qemu_ram.log; then echo "Kernel was successfully booted from RAM"; else echo "Failed to boot kernel from RAM"; fi
+if grep -q 'Successfully booted' qemu_emmc.log; then echo "Kernel was successfully booted from eMMC"; else echo "Failed to boot kernel from eMMC"; fi
+if grep -q 'Successfully booted' qemu_nand.log; then echo "Kernel was successfully booted from OneNAND"; else echo "Failed to boot kernel from OneNAND"; fi
+
+echo
+
+if grep -q 'Successfully booted' qemu_ram.log && grep -q 'Successfully booted' qemu_emmc.log && grep -q 'Successfully booted' qemu_nand.log; then
+	echo "All tests passed"
+	exit 0
+else
+	echo "Some tests failed"
+	exit 1
+fi
-- 
2.20.1

[PATCH v3] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Sunday 17 May 2020 14:38:22 Pali Roh?r wrote:
> This patch contains test/nokia_rx51_test.sh script which automatically
> download and compile all needed tools in local temporary directory to
> generate a simple MTD images for booting Maemo kernel image by U-Boot from
> RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
> provided by qemu-linaro project.
> 
> This script does not need any special privileges, so it can be run as
> non-root nobody user.
> 
> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> successfully booted in emulator.
> 
> Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
> .travis.yml so it would be automatically run on those CI services.
> 
> Signed-off-by: Pali Roh?r <pali@kernel.org>
> ---
> Changes in v3:
> * Fix job for Azure
> Changes in v2:
> * Fix apt dependences for Travis CI
> * Move definition of Travis job into own section
> * Add definition for Azure and Gitlab CI services
> * Add script to MAINTAINERS file
> * Build U-Boot binary in test script too
> * Show error message when some dependency for script is missing
> * Fix addresses for booting kernel from OneNAND
> * Do all stuff in nokia_rx51_tmp temporary directory
> * Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
>   (instead of mkfs.fat from dosfstools with custom patches)
> * Show more verbose log messages
> * Do not use sudo, instead run parts of script under fakeroot
>   (fakeroot just run binary with own LD_PRELOAD library which emulates
>    mknod() function for later usage by stat() function)
> * So script can be now run as non-root nobody user and it put all stuff
>   in nokia_rx51_tmp temporary directory, so can be run locally without
>   any issue.
> ---

Hello Tom! Have you looked at this updated V3 patch?

[PATCH v3] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Lokesh Vutla]

On 26/05/20 2:48 pm, Pali Roh?r wrote:
> On Sunday 17 May 2020 14:38:22 Pali Roh?r wrote:
>> This patch contains test/nokia_rx51_test.sh script which automatically
>> download and compile all needed tools in local temporary directory to
>> generate a simple MTD images for booting Maemo kernel image by U-Boot from
>> RAM, eMMC and OneNAND. MTD images are then run in virtual n900 machine
>> provided by qemu-linaro project.
>>
>> This script does not need any special privileges, so it can be run as
>> non-root nobody user.
>>
>> It can be used to check that U-Boot for Nokia N900 is not broken and can be
>> successfully booted in emulator.
>>
>> Script is registered to .azure-pipelines.yml, .gitlab-ci.yml and
>> .travis.yml so it would be automatically run on those CI services.
>>
>> Signed-off-by: Pali Roh?r <pali@kernel.org>
>> ---
>> Changes in v3:
>> * Fix job for Azure
>> Changes in v2:
>> * Fix apt dependences for Travis CI
>> * Move definition of Travis job into own section
>> * Add definition for Azure and Gitlab CI services
>> * Add script to MAINTAINERS file
>> * Build U-Boot binary in test script too
>> * Show error message when some dependency for script is missing
>> * Fix addresses for booting kernel from OneNAND
>> * Do all stuff in nokia_rx51_tmp temporary directory
>> * Use upstream mformat (from mtools) for generating FAT32 MBR filesystems
>>   (instead of mkfs.fat from dosfstools with custom patches)
>> * Show more verbose log messages
>> * Do not use sudo, instead run parts of script under fakeroot
>>   (fakeroot just run binary with own LD_PRELOAD library which emulates
>>    mknod() function for later usage by stat() function)
>> * So script can be now run as non-root nobody user and it put all stuff
>>   in nokia_rx51_tmp temporary directory, so can be run locally without
>>   any issue.
>> ---
> 
> Hello Tom! Have you looked at this updated V3 patch?
> 

Sorry, this was merged into master yesterday.

Thanks and regards,
Lokesh

[PATCH v3] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 26 May 2020 14:52:50 Lokesh Vutla wrote:
> On 26/05/20 2:48 pm, Pali Roh?r wrote:
> > Hello Tom! Have you looked at this updated V3 patch?
> > 
> 
> Sorry, this was merged into master yesterday.
> 
> Thanks and regards,
> Lokesh

Sorry, I have not looked into git repository yet.

So are all CI jobs working fine now?

[PATCH v3] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Lokesh Vutla]

On 26/05/20 3:02 pm, Pali Roh?r wrote:
> On Tuesday 26 May 2020 14:52:50 Lokesh Vutla wrote:
>> On 26/05/20 2:48 pm, Pali Roh?r wrote:
>>> Hello Tom! Have you looked at this updated V3 patch?
>>>
>>
>> Sorry, this was merged into master yesterday.
>>
>> Thanks and regards,
>> Lokesh
> 
> Sorry, I have not looked into git repository yet.
> 
> So are all CI jobs working fine now?

Yes.

Thanks and regards,
Lokesh
> 

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 21 April 2020 16:46:36 Tom Rini wrote:
> That's what the script does.  The problem is that we need a specific
> (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.

Not only specific commit, but specific fork! This is Linaro fork of qemu
(with support for OMAP3) which Linaro never upstreamed and fork is now
dead :-(

> So we can't replace the QEMU we use for everyone with one that also
> supports N900.

You really need that specific version of qemu to run it. Upstream qemu
has no support for N900 nor for OMAP3 HW.

Plus it needs proprietary Nokia's first stage bootloader (which starts
u-boot) with proprietary userspace tool which put this first stage
bootloader and configuration for it into MTD image. In MTD there is one
special partition with configuration data for this first stage
bootloader and that proprietary tool fill it. Tool and first stage
bootloader is under license which allows non-commercial redistribution

Why we need that first stage bootloader? Because on real N900 HW it is
signed and therefore cannot be replaced. Qemu version of that first
stage bootloader is obviously not signed.

[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Pali Rohár]

On Tuesday 21 April 2020 14:37:45 Simon Glass wrote:
> Hi,
> 
> On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla@ti.com> wrote:
> > > >
> > > > Tom,
> > > >
> > > > On 14/04/20 4:10 PM, Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 00:35:18 Pali Roh?r wrote:
> > > > >> This patch contains a script which automatically download and compile all
> > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > >> machine provided by qemu-linaro project.
> > > > >>
> > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > >> successfully booted in emulator.
> > > > >>
> > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > >> Travi CI service.
> > > > >>
> > > > >> Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > >
> > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > please review this patch (including fixup at the bottom)?
> > > >
> > > > Can you ack this patch?
> > >
> > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> >
> > Well, this is where it's tricky and I've been debating with myself on
> > how to move forward here.
> >
> > Part of the problem here is that much like a Pi, we could emulate this
> > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > there's not a lot of these devices around to test with.  It's not a big
> > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > has a Pi and other labs could add one fairly easy.  But adding an N900
> > to a lab is hard.
> >
> > Looking over the script to do it, there's a lot of other stuff required
> > too, for it all to work.  Looking over the script again, there's enough
> > stuff going on that I wouldn't want it done in a persistent
> > image/container.
> >
> > The only changes I would ask for I guess are that it should be put in
> > .travis.yml in the same areas other non-pytest tests, and put in similar
> > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> 
> For the existing stuff we use some sort of qemu that is built into the
> image, so far as I understand it. Is that right?
> 
> Could we do something similar here? I actually don't like that though,
> since there is so much setup needed to run things locally (without
> docker).

That script run u-boot in n900 qemu machine and test that u-boot can
correctly boot Maemo kernel (from RAM, eMMC and OneNAND) with simple
rootfs. So it is full u-boot test for n900. And basically simulates
whole bootloader process for Maemo. In this case I'm sure that
everything is fine and I can replace new u-boot binary without
introducing any regressions. 

It downloads all needed stuff to construct images and filesystems.

> Also, what is to stop me running this script on my machine?

In script is "sudo mknod rootfs/dev/console c 5 1" call as in rootfs is
needed /dev/console character device. Otherwise everything is called
under normal user and all stuff is put into current directory.

And because on travis we can use 'sudo' I chosen this solution.

Alternative way to avoid usage of sudo, is to run whole script under
"fakeroot" utility. It use LD_PRELOAD with own library to fake mknod and
stat functions, so process can mknod (in memory) character device and
then mkfs.ubifs which reads (via stat) all files can properly put
character devices into rootfs image -- without any root privilege
escalation.

So if you want to run it on your machine, you needs be aware of that
sudo call.

Or if you want I can change script to use fakeroot utility (e.g Debian
is using it for building any DEB package) and then you can run it safely
under "nobody" user locally on your machine (if you do not like that
sudo call).

> Regards,
> Simon

U-Boot is broken on real N900 HW (Was: Re: [PATCH 00/11] Fixes for Nokia RX-51)

[Pali Rohár]

On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> This patch series contain fixes for Nokia RX-51 board (aka N900).
> After these changes it is possible to run U-Boot in qemu emulator again.
> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> problem.

But on real Nokia N900 device is U-Boot crashing in reboot loop.

I do not have serial console for Nokia N900 to debug this issue, but
seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
that there is no crash and even no error in qemu emulator so I cannot
debug this issue.

First problem is around /* reset lp5523 led */ code in rx51.c. On real
N900 device it generates repeating messages:

  Check if pads/pull-ups of bus are properly configured
  Timed out in wait_for_event: status=0000

When I commented that few lines all these messages disappeared. So
problem is with OMAP I2C.

Second problem happen after misc_init_r() function finishes. U-Boot just
prints on N900 screen message "data abort" and reboots. As I do not have
serial console it is hard to debug. but I figured out that problem is in
mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
debug info prior to mmc_set_ios() call and after it, and debug info
prior was printed, not after.

I remember that somebody had serial jig for Nokia N900, could somebody
look at this reboot loop problem?

And any idea how should be OMAP I2C configured in U-Boot to correctly
work?

Maybe I will try to find some time to git bisect which change broke
U-Boot on real N900 hardware.

U-Boot is broken on real N900 HW

[Pali Rohár]

On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> Hi,
> 
> On 01/04/2020 00:42, Pali Roh?r wrote:
> > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >> After these changes it is possible to run U-Boot in qemu emulator again.
> >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >> problem.
> > 
> > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > 
> > I do not have serial console for Nokia N900 to debug this issue, but
> > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > that there is no crash and even no error in qemu emulator so I cannot
> > debug this issue.
> > 
> > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > N900 device it generates repeating messages:
> > 
> >   Check if pads/pull-ups of bus are properly configured
> >   Timed out in wait_for_event: status=0000
> > 
> > When I commented that few lines all these messages disappeared. So
> > problem is with OMAP I2C.
> > 
> > Second problem happen after misc_init_r() function finishes. U-Boot just
> > prints on N900 screen message "data abort" and reboots. As I do not have
> > serial console it is hard to debug. but I figured out that problem is in
> > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > debug info prior to mmc_set_ios() call and after it, and debug info
> > prior was printed, not after.
> > 
> > I remember that somebody had serial jig for Nokia N900, could somebody
> > look at this reboot loop problem?
> > 
> > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > work?
> > 
> > Maybe I will try to find some time to git bisect which change broke
> > U-Boot on real N900 hardware.
> 
> Took latest u-boot master, applied patches and this is the result on
> serial (first part is NOLO booting, I think that can be ignored) [1].

...

> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> 
> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> Nokia RX-51 + LPDDR/OneNAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  0 Bytes

Looks like that something with NAND is broken.

> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> In:    vga
> Out:   vga
> Err:   vga
> Timed out in wait_for_event: status=0100
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=0000
> Check if pads/pull-ups of bus are properly configured
> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> i2c_write: timed out writig last byte!

These i2c errors are caused by

	/* reset lp5523 led */
	i2c_set_bus_num(1);
	state = 0xff;
	i2c_write(0x32, 0x3d, 1, &state, 1);
	i2c_set_bus_num(0);

Is there anything which needs to be done to initialize i2c bus 1?
Because this code is working fine on older U-Boot version.

Was something changed to OMAP i2c bus code in U-Boot?

> OMAP die ID: 031400240000000004036ac10b01100f
> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> 

And then U-Boot freeze, right?

Any idea how to debug this issue?

On my N900 I'm getting "data abort" error on display and then instant
reboot.

U-Boot is broken on real N900 HW

[Pali Rohár]

On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > Hi,
> > 
> > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > >> problem.
> > > 
> > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > 
> > > I do not have serial console for Nokia N900 to debug this issue, but
> > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > that there is no crash and even no error in qemu emulator so I cannot
> > > debug this issue.
> > > 
> > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > N900 device it generates repeating messages:
> > > 
> > >   Check if pads/pull-ups of bus are properly configured
> > >   Timed out in wait_for_event: status=0000
> > > 
> > > When I commented that few lines all these messages disappeared. So
> > > problem is with OMAP I2C.
> > > 
> > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > serial console it is hard to debug. but I figured out that problem is in
> > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > prior was printed, not after.
> > > 
> > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > look at this reboot loop problem?
> > > 
> > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > work?
> > > 
> > > Maybe I will try to find some time to git bisect which change broke
> > > U-Boot on real N900 hardware.
> > 
> > Took latest u-boot master, applied patches and this is the result on
> > serial (first part is NOLO booting, I think that can be ignored) [1].
> 
> ...
> 
> > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > 
> > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > Nokia RX-51 + LPDDR/OneNAND
> > I2C:   ready
> > DRAM:  256 MiB
> > NAND:  0 Bytes
> 
> Looks like that something with NAND is broken.
> 
> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > In:    vga
> > Out:   vga
> > Err:   vga
> > Timed out in wait_for_event: status=0100
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=0000
> > Check if pads/pull-ups of bus are properly configured
> > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > i2c_write: timed out writig last byte!
> 
> These i2c errors are caused by
> 
> 	/* reset lp5523 led */
> 	i2c_set_bus_num(1);
> 	state = 0xff;
> 	i2c_write(0x32, 0x3d, 1, &state, 1);
> 	i2c_set_bus_num(0);
> 
> Is there anything which needs to be done to initialize i2c bus 1?
> Because this code is working fine on older U-Boot version.

Above code worked fine for U-Boot 2013.04, but in git version from
January 2015 it prints above error messages.

On on internet forums I see these error messages also from other OMAP3
board, e.g. beagle board.

Has somebody some working OMAP3 board? And can test if it works with
recent version of U-Boot? I guess that above i2c problem would happen
also on other OMAP3 boards.

> Was something changed to OMAP i2c bus code in U-Boot?
> 
> > OMAP die ID: 031400240000000004036ac10b01100f
> > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > 
> 
> And then U-Boot freeze, right?
> 
> Any idea how to debug this issue?
> 
> On my N900 I'm getting "data abort" error on display and then instant
> reboot.

It looks like that omap hs mmc code cause that freeze/reboot on real HW.
Was there some significat change to OMAP3 or omap hs mmc?

U-Boot is broken on real N900 HW

[Adam Ford]

On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>
> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > Hi,
> > >
> > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > >> problem.
> > > >
> > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > >
> > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > debug this issue.
> > > >
> > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > N900 device it generates repeating messages:
> > > >
> > > >   Check if pads/pull-ups of bus are properly configured
> > > >   Timed out in wait_for_event: status=0000
> > > >
> > > > When I commented that few lines all these messages disappeared. So
> > > > problem is with OMAP I2C.
> > > >
> > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > serial console it is hard to debug. but I figured out that problem is in
> > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > prior was printed, not after.
> > > >
> > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > look at this reboot loop problem?
> > > >
> > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > work?
> > > >
> > > > Maybe I will try to find some time to git bisect which change broke
> > > > U-Boot on real N900 hardware.
> > >
> > > Took latest u-boot master, applied patches and this is the result on
> > > serial (first part is NOLO booting, I think that can be ignored) [1].
> >
> > ...
> >
> > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > >
> > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > Nokia RX-51 + LPDDR/OneNAND
> > > I2C:   ready
> > > DRAM:  256 MiB
> > > NAND:  0 Bytes
> >
> > Looks like that something with NAND is broken.
> >
> > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > In:    vga
> > > Out:   vga
> > > Err:   vga
> > > Timed out in wait_for_event: status=0100
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=0000
> > > Check if pads/pull-ups of bus are properly configured
> > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > i2c_write: timed out writig last byte!
> >
> > These i2c errors are caused by
> >
> >       /* reset lp5523 led */
> >       i2c_set_bus_num(1);
> >       state = 0xff;
> >       i2c_write(0x32, 0x3d, 1, &state, 1);
> >       i2c_set_bus_num(0);
> >
> > Is there anything which needs to be done to initialize i2c bus 1?
> > Because this code is working fine on older U-Boot version.
>
> Above code worked fine for U-Boot 2013.04, but in git version from
> January 2015 it prints above error messages.
>
> On on internet forums I see these error messages also from other OMAP3
> board, e.g. beagle board.
>
> Has somebody some working OMAP3 board? And can test if it works with
> recent version of U-Boot? I guess that above i2c problem would happen
> also on other OMAP3 boards.

There was a conversion a while ago to dm_i2c, and I converted my board
to support using the device tree during the SPL phase, and whenever I
am aware any driver has driver model (DM) support, I try to convert my
board.

I have a DM3730 and the last check I did was 2020.04-rc1, and it was working

U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
Trying to boot from MMC1
spl_load_image_fat_os: error reading image args, err - -2


U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
Logic DM37x/OMAP35x reference board + LPDDR/NAND
DRAM:  256 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0
Loading Environment from NAND... OK
OMAP die ID: 619e00029ff800000168300f1502501f
Net:   eth0: ethernet at 08000000
Hit any key to stop autoboot:  2

>
> > Was something changed to OMAP i2c bus code in U-Boot?
> >
> > > OMAP die ID: 031400240000000004036ac10b01100f
> > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > >
> >
> > And then U-Boot freeze, right?
> >
> > Any idea how to debug this issue?
> >
> > On my N900 I'm getting "data abort" error on display and then instant
> > reboot.
>
> It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> Was there some significat change to OMAP3 or omap hs mmc?

I booted by board from MMC as shown above.  I also use the pinctrl
features from the device tree to mux the pins in U-Boot (not SPL), so
my SPL only does manual muxing the essential components it needs
during the SPL phase, and lets U-Boot do the rest.   I only  mention
the pinmux because of message regarding pads/pull-ups.

adam

U-Boot is broken on real N900 HW

[Pali Rohár]

On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> >
> > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > Hi,
> > > >
> > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > >> problem.
> > > > >
> > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > >
> > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > debug this issue.
> > > > >
> > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > N900 device it generates repeating messages:
> > > > >
> > > > >   Check if pads/pull-ups of bus are properly configured
> > > > >   Timed out in wait_for_event: status=0000
> > > > >
> > > > > When I commented that few lines all these messages disappeared. So
> > > > > problem is with OMAP I2C.
> > > > >
> > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > prior was printed, not after.
> > > > >
> > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > look at this reboot loop problem?
> > > > >
> > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > work?
> > > > >
> > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > U-Boot on real N900 hardware.
> > > >
> > > > Took latest u-boot master, applied patches and this is the result on
> > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > >
> > > ...
> > >
> > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > >
> > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > Nokia RX-51 + LPDDR/OneNAND
> > > > I2C:   ready
> > > > DRAM:  256 MiB
> > > > NAND:  0 Bytes
> > >
> > > Looks like that something with NAND is broken.
> > >
> > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > In:    vga
> > > > Out:   vga
> > > > Err:   vga
> > > > Timed out in wait_for_event: status=0100
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=0000
> > > > Check if pads/pull-ups of bus are properly configured
> > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > i2c_write: timed out writig last byte!
> > >
> > > These i2c errors are caused by
> > >
> > >       /* reset lp5523 led */
> > >       i2c_set_bus_num(1);
> > >       state = 0xff;
> > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > >       i2c_set_bus_num(0);
> > >
> > > Is there anything which needs to be done to initialize i2c bus 1?
> > > Because this code is working fine on older U-Boot version.
> >
> > Above code worked fine for U-Boot 2013.04, but in git version from
> > January 2015 it prints above error messages.
> >
> > On on internet forums I see these error messages also from other OMAP3
> > board, e.g. beagle board.
> >
> > Has somebody some working OMAP3 board? And can test if it works with
> > recent version of U-Boot? I guess that above i2c problem would happen
> > also on other OMAP3 boards.
> 
> There was a conversion a while ago to dm_i2c, and I converted my board
> to support using the device tree during the SPL phase, and whenever I
> am aware any driver has driver model (DM) support, I try to convert my
> board.
> 
> I have a DM3730 and the last check I did was 2020.04-rc1, and it was working

Ok, so it either OMAP3430 specific problem or N900 board specific
problem. N900 does not use driver model.

Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
it returned error.

If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
and basically U-Boot stopped responding.

So by above observation it looks like I2C bus num 1 does not work, but
I2C bus num 0 works fine.

Do I need to call i2c_probe(...) before calling i2c_write(...)?

And is something special needed for initializing omap i2c bus num 1?
Because from my above observation it looks like that something is
missing for bus 1 which in older u-boot version was not needed.

> U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> Trying to boot from MMC1
> spl_load_image_fat_os: error reading image args, err - -2
> 
> 
> U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> 
> OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> Logic DM37x/OMAP35x reference board + LPDDR/NAND
> DRAM:  256 MiB
> NAND:  512 MiB
> MMC:   OMAP SD/MMC: 0
> Loading Environment from NAND... OK
> OMAP die ID: 619e00029ff800000168300f1502501f
> Net:   eth0: ethernet at 08000000
> Hit any key to stop autoboot:  2
> 
> >
> > > Was something changed to OMAP i2c bus code in U-Boot?
> > >
> > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > >
> > >
> > > And then U-Boot freeze, right?
> > >
> > > Any idea how to debug this issue?
> > >
> > > On my N900 I'm getting "data abort" error on display and then instant
> > > reboot.
> >
> > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > Was there some significat change to OMAP3 or omap hs mmc?
> 
> I booted by board from MMC as shown above.  I also use the pinctrl
> features from the device tree to mux the pins in U-Boot (not SPL), so
> my SPL only does manual muxing the essential components it needs
> during the SPL phase, and lets U-Boot do the rest.   I only  mention
> the pinmux because of message regarding pads/pull-ups.
> 
> adam

I debugged this problem more. I disabled all preboot commands to get
clean U-Boot setup. And it worked.

After I called any "mmc" command (e.g. "mmc info") I got that instant
board reboot. Preboot commands for n900 try to read some files from mmc,
so this is reason why it get into reboot loop.

Is there any reason why "mmc info" command can cause "data abort" and
instant reboot of board?

And do you know what is needed for proper initialization of omap mmc
controller for omap3 board? Because it looks like something fundamental
is missing.

Currently there are just calls for "omap_mmc_init()" functions and
"twl4030_power_mmc_init()" functions. See:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

U-Boot is broken on real N900 HW

[Adam Ford]

On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>
> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > Hi,
> > > > >
> > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > >> problem.
> > > > > >
> > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > >
> > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > debug this issue.
> > > > > >
> > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > N900 device it generates repeating messages:
> > > > > >
> > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > >   Timed out in wait_for_event: status=0000
> > > > > >
> > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > problem is with OMAP I2C.
> > > > > >
> > > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > > prior was printed, not after.
> > > > > >
> > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > look at this reboot loop problem?
> > > > > >
> > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > work?
> > > > > >
> > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > U-Boot on real N900 hardware.
> > > > >
> > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > >
> > > > ...
> > > >
> > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > >
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > I2C:   ready
> > > > > DRAM:  256 MiB
> > > > > NAND:  0 Bytes
> > > >
> > > > Looks like that something with NAND is broken.
> > > >
> > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > In:    vga
> > > > > Out:   vga
> > > > > Err:   vga
> > > > > Timed out in wait_for_event: status=0100
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > i2c_write: timed out writig last byte!
> > > >
> > > > These i2c errors are caused by
> > > >
> > > >       /* reset lp5523 led */
> > > >       i2c_set_bus_num(1);
> > > >       state = 0xff;
> > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > >       i2c_set_bus_num(0);
> > > >
> > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > Because this code is working fine on older U-Boot version.
> > >
> > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > January 2015 it prints above error messages.
> > >
> > > On on internet forums I see these error messages also from other OMAP3
> > > board, e.g. beagle board.
> > >
> > > Has somebody some working OMAP3 board? And can test if it works with
> > > recent version of U-Boot? I guess that above i2c problem would happen
> > > also on other OMAP3 boards.
> >
> > There was a conversion a while ago to dm_i2c, and I converted my board
> > to support using the device tree during the SPL phase, and whenever I
> > am aware any driver has driver model (DM) support, I try to convert my
> > board.
> >
> > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
>
> Ok, so it either OMAP3430 specific problem or N900 board specific
> problem. N900 does not use driver model.

i have an OMAP3530 which is basically a 3430, and it works too.  I am
guessing the issue is unique to the N900 or the fact that it's
high-security.  Neither of my boards are HS parts.  They are both GP.

I would highly consider migrating to the driver model if you can.
Using the driver model, I was able to greatly reduce the size of board
file and the manual initialization of drivers, because the DM does
that for you.
I also know they're advocating removing boards which do not comply
with the DM requirements.

>
> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> it returned error.
>
> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> and basically U-Boot stopped responding.
>
> So by above observation it looks like I2C bus num 1 does not work, but
> I2C bus num 0 works fine.
>
> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>
> And is something special needed for initializing omap i2c bus num 1?
> Because from my above observation it looks like that something is
> missing for bus 1 which in older u-boot version was not needed.
>
> > U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> > Trying to boot from MMC1
> > spl_load_image_fat_os: error reading image args, err - -2
> >
> >
> > U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> >
> > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > DRAM:  256 MiB
> > NAND:  512 MiB
> > MMC:   OMAP SD/MMC: 0
> > Loading Environment from NAND... OK
> > OMAP die ID: 619e00029ff800000168300f1502501f
> > Net:   eth0: ethernet at 08000000
> > Hit any key to stop autoboot:  2
> >
> > >
> > > > Was something changed to OMAP i2c bus code in U-Boot?
> > > >
> > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > >
> > > >
> > > > And then U-Boot freeze, right?
> > > >
> > > > Any idea how to debug this issue?
> > > >
> > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > reboot.
> > >
> > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > Was there some significat change to OMAP3 or omap hs mmc?
> >
> > I booted by board from MMC as shown above.  I also use the pinctrl
> > features from the device tree to mux the pins in U-Boot (not SPL), so
> > my SPL only does manual muxing the essential components it needs
> > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > the pinmux because of message regarding pads/pull-ups.
> >
> > adam
>
> I debugged this problem more. I disabled all preboot commands to get
> clean U-Boot setup. And it worked.
>
> After I called any "mmc" command (e.g. "mmc info") I got that instant
> board reboot. Preboot commands for n900 try to read some files from mmc,
> so this is reason why it get into reboot loop.
>
> Is there any reason why "mmc info" command can cause "data abort" and
> instant reboot of board?
>
> And do you know what is needed for proper initialization of omap mmc
> controller for omap3 board? Because it looks like something fundamental
> is missing.
>
> Currently there are just calls for "omap_mmc_init()" functions and
> "twl4030_power_mmc_init()" functions. See:
> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

U-Boot is broken on real N900 HW

[Pali Rohár]

On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
> >
> > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > >
> > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > > >> problem.
> > > > > > >
> > > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > > >
> > > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > > debug this issue.
> > > > > > >
> > > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > > N900 device it generates repeating messages:
> > > > > > >
> > > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > > >   Timed out in wait_for_event: status=0000
> > > > > > >
> > > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > > problem is with OMAP I2C.
> > > > > > >
> > > > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > > > prior was printed, not after.
> > > > > > >
> > > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > > look at this reboot loop problem?
> > > > > > >
> > > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > > work?
> > > > > > >
> > > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > > U-Boot on real N900 hardware.
> > > > > >
> > > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > > >
> > > > > ...
> > > > >
> > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > >
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > I2C:   ready
> > > > > > DRAM:  256 MiB
> > > > > > NAND:  0 Bytes
> > > > >
> > > > > Looks like that something with NAND is broken.
> > > > >
> > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > In:    vga
> > > > > > Out:   vga
> > > > > > Err:   vga
> > > > > > Timed out in wait_for_event: status=0100
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > i2c_write: timed out writig last byte!
> > > > >
> > > > > These i2c errors are caused by
> > > > >
> > > > >       /* reset lp5523 led */
> > > > >       i2c_set_bus_num(1);
> > > > >       state = 0xff;
> > > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > > >       i2c_set_bus_num(0);
> > > > >
> > > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > > Because this code is working fine on older U-Boot version.
> > > >
> > > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > > January 2015 it prints above error messages.
> > > >
> > > > On on internet forums I see these error messages also from other OMAP3
> > > > board, e.g. beagle board.
> > > >
> > > > Has somebody some working OMAP3 board? And can test if it works with
> > > > recent version of U-Boot? I guess that above i2c problem would happen
> > > > also on other OMAP3 boards.
> > >
> > > There was a conversion a while ago to dm_i2c, and I converted my board
> > > to support using the device tree during the SPL phase, and whenever I
> > > am aware any driver has driver model (DM) support, I try to convert my
> > > board.
> > >
> > > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> >
> > Ok, so it either OMAP3430 specific problem or N900 board specific
> > problem. N900 does not use driver model.
> 
> i have an OMAP3530 which is basically a 3430, and it works too.  I am
> guessing the issue is unique to the N900 or the fact that it's
> high-security.  Neither of my boards are HS parts.  They are both GP.

N900 is HS device, but I guess that should be caused by GP vs HS
difference. Working i2c bus 0 and non-working i2c bus 1 could not be
caused by GP vs HS difference. Also I guess that omap hs mmc would be
same on GP and HS boards.

> I would highly consider migrating to the driver model if you can.

Until it works correctly, I cannot do migration.

> Using the driver model, I was able to greatly reduce the size of board
> file and the manual initialization of drivers, because the DM does
> that for you.
> I also know they're advocating removing boards which do not comply
> with the DM requirements.
> 
> >
> > Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> > it returned error.
> >
> > If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> > and basically U-Boot stopped responding.
> >
> > So by above observation it looks like I2C bus num 1 does not work, but
> > I2C bus num 0 works fine.
> >
> > Do I need to call i2c_probe(...) before calling i2c_write(...)?
> >
> > And is something special needed for initializing omap i2c bus num 1?
> > Because from my above observation it looks like that something is
> > missing for bus 1 which in older u-boot version was not needed.
> >
> > > U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> > > Trying to boot from MMC1
> > > spl_load_image_fat_os: error reading image args, err - -2
> > >
> > >
> > > U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> > >
> > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > > DRAM:  256 MiB
> > > NAND:  512 MiB
> > > MMC:   OMAP SD/MMC: 0
> > > Loading Environment from NAND... OK
> > > OMAP die ID: 619e00029ff800000168300f1502501f
> > > Net:   eth0: ethernet at 08000000
> > > Hit any key to stop autoboot:  2
> > >
> > > >
> > > > > Was something changed to OMAP i2c bus code in U-Boot?
> > > > >
> > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > >
> > > > >
> > > > > And then U-Boot freeze, right?
> > > > >
> > > > > Any idea how to debug this issue?
> > > > >
> > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > reboot.
> > > >
> > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > Was there some significat change to OMAP3 or omap hs mmc?
> > >
> > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > my SPL only does manual muxing the essential components it needs
> > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > the pinmux because of message regarding pads/pull-ups.
> > >
> > > adam
> >
> > I debugged this problem more. I disabled all preboot commands to get
> > clean U-Boot setup. And it worked.
> >
> > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > board reboot. Preboot commands for n900 try to read some files from mmc,
> > so this is reason why it get into reboot loop.
> >
> > Is there any reason why "mmc info" command can cause "data abort" and
> > instant reboot of board?
> >
> > And do you know what is needed for proper initialization of omap mmc
> > controller for omap3 board? Because it looks like something fundamental
> > is missing.
> >
> > Currently there are just calls for "omap_mmc_init()" functions and
> > "twl4030_power_mmc_init()" functions. See:
> > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

U-Boot i2c bus num 1 is broken on Nokia N900 (Was: Re: U-Boot is broken on real N900 HW)

[Pali Rohár]

Adding Hannes and Heiko to the loop, please look at this problem.

On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
> > On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > >
> > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > > > >> problem.
> > > > > > > >
> > > > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > > > >
> > > > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > > > debug this issue.
> > > > > > > >
> > > > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > > > N900 device it generates repeating messages:
> > > > > > > >
> > > > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > > > >   Timed out in wait_for_event: status=0000
> > > > > > > >
> > > > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > > > problem is with OMAP I2C.
...
> > > > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > > > look at this reboot loop problem?
> > > > > > > >
> > > > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > > > work?
> > > > > > > >
> > > > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > > > U-Boot on real N900 hardware.
> > > > > > >
> > > > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > > >
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > > I2C:   ready
> > > > > > > DRAM:  256 MiB
> > > > > > > NAND:  0 Bytes
> > > > > >
> > > > > > Looks like that something with NAND is broken.
> > > > > >
> > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > > In:    vga
> > > > > > > Out:   vga
> > > > > > > Err:   vga
> > > > > > > Timed out in wait_for_event: status=0100
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > > i2c_write: timed out writig last byte!
> > > > > >
> > > > > > These i2c errors are caused by
> > > > > >
> > > > > >       /* reset lp5523 led */
> > > > > >       i2c_set_bus_num(1);
> > > > > >       state = 0xff;
> > > > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > > > >       i2c_set_bus_num(0);
> > > > > >
> > > > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > > > Because this code is working fine on older U-Boot version.
> > > > >
> > > > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > > > January 2015 it prints above error messages.
> > > > >
> > > > > On on internet forums I see these error messages also from other OMAP3
> > > > > board, e.g. beagle board.
> > > > >
> > > > > Has somebody some working OMAP3 board? And can test if it works with
> > > > > recent version of U-Boot? I guess that above i2c problem would happen
> > > > > also on other OMAP3 boards.
> > > >
> > > > There was a conversion a while ago to dm_i2c, and I converted my board
> > > > to support using the device tree during the SPL phase, and whenever I
> > > > am aware any driver has driver model (DM) support, I try to convert my
> > > > board.
> > > >
> > > > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> > >
> > > Ok, so it either OMAP3430 specific problem or N900 board specific
> > > problem. N900 does not use driver model.
> > 
> > i have an OMAP3530 which is basically a 3430, and it works too.  I am
> > guessing the issue is unique to the N900 or the fact that it's
> > high-security.  Neither of my boards are HS parts.  They are both GP.
> 
> N900 is HS device, but I guess that should be caused by GP vs HS
> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
> caused by GP vs HS difference. Also I guess that omap hs mmc would be
> same on GP and HS boards.
...
> > > Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> > > it returned error.
> > >
> > > If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> > > and basically U-Boot stopped responding.
> > >
> > > So by above observation it looks like I2C bus num 1 does not work, but
> > > I2C bus num 0 works fine.
> > >
> > > Do I need to call i2c_probe(...) before calling i2c_write(...)?
> > >
> > > And is something special needed for initializing omap i2c bus num 1?
> > > Because from my above observation it looks like that something is
> > > missing for bus 1 which in older u-boot version was not needed.

Now I was able to find commit which is causing above i2c problems:
"Check if pads/pull-ups of bus are properly configured"

It is d5243359e1afc957acd373dbbde1cf6c70ee5485:

    OMAP24xx I2C: Add support for set-speed
    
    Adds support for set-speed on the OMAP24xx I2C Adapter.
    
    Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
    Otherwise on a subsequent call the transfer of last byte from the
    predecessor is aborted and therefore lost. For exmaple when
    i2c_write(...) is followed by a i2c_setspeed(...) (which has to
    deactivate and activate master for changing psc,...).
    
    Minor cosmetical changes.
    
    Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
    Cc: Heiko Schocher <hs@denx.de>

U-Boot version prior this command does not report those i2c errors.

Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
Nokia N900?

U-Boot i2c bus num 1 is broken on Nokia N900 (Was: Re: U-Boot is broken on real N900 HW)

[Heiko Schocher]

Hello Pali,

Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
> Adding Hannes and Heiko to the loop, please look at this problem.
> 
> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>
>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>
>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot loop.
>>>>>>>>>
>>>>>>>>> I do not have serial console for Nokia N900 to debug this issue, but
>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
>>>>>>>>> that there is no crash and even no error in qemu emulator so I cannot
>>>>>>>>> debug this issue.
>>>>>>>>>
>>>>>>>>> First problem is around /* reset lp5523 led */ code in rx51.c. On real
>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>
>>>>>>>>>    Check if pads/pull-ups of bus are properly configured
>>>>>>>>>    Timed out in wait_for_event: status=0000
>>>>>>>>>
>>>>>>>>> When I commented that few lines all these messages disappeared. So
>>>>>>>>> problem is with OMAP I2C.
> ...
>>>>>>>>> I remember that somebody had serial jig for Nokia N900, could somebody
>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>
>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot to correctly
>>>>>>>>> work?
>>>>>>>>>
>>>>>>>>> Maybe I will try to find some time to git bisect which change broke
>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>
>>>>>>>> Took latest u-boot master, applied patches and this is the result on
>>>>>>>> serial (first part is NOLO booting, I think that can be ignored) [1].
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
>>>>>>>>
>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>> I2C:   ready
>>>>>>>> DRAM:  256 MiB
>>>>>>>> NAND:  0 Bytes
>>>>>>>
>>>>>>> Looks like that something with NAND is broken.

The board code in U-Boot is in a very old state... :-(

>>>>>>>
>>>>>>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>> In:    vga
>>>>>>>> Out:   vga
>>>>>>>> Err:   vga
>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>
>>>>>>> These i2c errors are caused by
>>>>>>>
>>>>>>>        /* reset lp5523 led */
>>>>>>>        i2c_set_bus_num(1);

deprecated ... the board code needs cleanup ...

>>>>>>>        state = 0xff;
>>>>>>>        i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>        i2c_set_bus_num(0);
>>>>>>>
>>>>>>> Is there anything which needs to be done to initialize i2c bus 1?
>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>
>>>>>> Above code worked fine for U-Boot 2013.04, but in git version from
>>>>>> January 2015 it prints above error messages.
>>>>>>
>>>>>> On on internet forums I see these error messages also from other OMAP3
>>>>>> board, e.g. beagle board.
>>>>>>
>>>>>> Has somebody some working OMAP3 board? And can test if it works with
>>>>>> recent version of U-Boot? I guess that above i2c problem would happen
>>>>>> also on other OMAP3 boards.
>>>>>
>>>>> There was a conversion a while ago to dm_i2c, and I converted my board
>>>>> to support using the device tree during the SPL phase, and whenever I
>>>>> am aware any driver has driver model (DM) support, I try to convert my
>>>>> board.
>>>>>
>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
>>>>
>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>> problem. N900 does not use driver model.
>>>
>>> i have an OMAP3530 which is basically a 3430, and it works too.  I am
>>> guessing the issue is unique to the N900 or the fact that it's
>>> high-security.  Neither of my boards are HS parts.  They are both GP.
>>
>> N900 is HS device, but I guess that should be caused by GP vs HS
>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>> caused by GP vs HS difference. Also I guess that omap hs mmc would be
>> same on GP and HS boards.
> ...
>>>> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
>>>> it returned error.
>>>>
>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
>>>> and basically U-Boot stopped responding.
>>>>
>>>> So by above observation it looks like I2C bus num 1 does not work, but
>>>> I2C bus num 0 works fine.
>>>>
>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>
>>>> And is something special needed for initializing omap i2c bus num 1?
>>>> Because from my above observation it looks like that something is
>>>> missing for bus 1 which in older u-boot version was not needed.
> 
> Now I was able to find commit which is causing above i2c problems:
> "Check if pads/pull-ups of bus are properly configured"
> 
> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
> 
>      OMAP24xx I2C: Add support for set-speed
>      
>      Adds support for set-speed on the OMAP24xx I2C Adapter.
>      
>      Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
>      Otherwise on a subsequent call the transfer of last byte from the
>      predecessor is aborted and therefore lost. For exmaple when
>      i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>      deactivate and activate master for changing psc,...).
>      
>      Minor cosmetical changes.
>      
>      Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>      Cc: Heiko Schocher <hs@denx.de>
> 
> U-Boot version prior this command does not report those i2c errors.
> 
> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
> Nokia N900?

Hard to say here anything useful, as I do not have the hardware...

The above commit changes:

-               udelay(I2C_WAIT);
+               udelay(adap->waitdelay);

May you can check, if adap->waitdelay is the same as I2C_WAIT ?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Pali Rohár]

On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
> Hello Pali,
> 
> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
> > Adding Hannes and Heiko to the loop, please look at this problem.
> > 
> > On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
> > > On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
> > > > On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > > 
> > > > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > > > > 
> > > > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > > > > > > > This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > > > > > > > After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > > > > > > > And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > > > > > > > problem.
> > > > > > > > > > 
> > > > > > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > > > > > > 
> > > > > > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > > > > > debug this issue.
> > > > > > > > > > 
> > > > > > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > > > > > N900 device it generates repeating messages:
> > > > > > > > > > 
> > > > > > > > > >    Check if pads/pull-ups of bus are properly configured
> > > > > > > > > >    Timed out in wait_for_event: status=0000
> > > > > > > > > > 
> > > > > > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > > > > > problem is with OMAP I2C.
> > ...
> > > > > > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > > > > > look at this reboot loop problem?
> > > > > > > > > > 
> > > > > > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > > > > > work?
> > > > > > > > > > 
> > > > > > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > > > > > U-Boot on real N900 hardware.
> > > > > > > > > 
> > > > > > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > > > > > > 
> > > > > > > > ...
> > > > > > > > 
> > > > > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > > > > > 
> > > > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > > > > I2C:   ready
> > > > > > > > > DRAM:  256 MiB
> > > > > > > > > NAND:  0 Bytes
> > > > > > > > 
> > > > > > > > Looks like that something with NAND is broken.
> 
> The board code in U-Boot is in a very old state... :-(
> 
> > > > > > > > 
> > > > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > > > > In:    vga
> > > > > > > > > Out:   vga
> > > > > > > > > Err:   vga
> > > > > > > > > Timed out in wait_for_event: status=0100
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > > > > i2c_write: timed out writig last byte!
> > > > > > > > 
> > > > > > > > These i2c errors are caused by
> > > > > > > > 
> > > > > > > >        /* reset lp5523 led */
> > > > > > > >        i2c_set_bus_num(1);
> 
> deprecated ... the board code needs cleanup ...

I converted code to CONFIG_DM_I2C and nothing was changed, issue is
still there...

> > > > > > > >        state = 0xff;
> > > > > > > >        i2c_write(0x32, 0x3d, 1, &state, 1);
> > > > > > > >        i2c_set_bus_num(0);
> > > > > > > > 
> > > > > > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > > > > > Because this code is working fine on older U-Boot version.
> > > > > > > 
> > > > > > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > > > > > January 2015 it prints above error messages.
> > > > > > > 
> > > > > > > On on internet forums I see these error messages also from other OMAP3
> > > > > > > board, e.g. beagle board.
> > > > > > > 
> > > > > > > Has somebody some working OMAP3 board? And can test if it works with
> > > > > > > recent version of U-Boot? I guess that above i2c problem would happen
> > > > > > > also on other OMAP3 boards.
> > > > > > 
> > > > > > There was a conversion a while ago to dm_i2c, and I converted my board
> > > > > > to support using the device tree during the SPL phase, and whenever I
> > > > > > am aware any driver has driver model (DM) support, I try to convert my
> > > > > > board.
> > > > > > 
> > > > > > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> > > > > 
> > > > > Ok, so it either OMAP3430 specific problem or N900 board specific
> > > > > problem. N900 does not use driver model.
> > > > 
> > > > i have an OMAP3530 which is basically a 3430, and it works too.  I am
> > > > guessing the issue is unique to the N900 or the fact that it's
> > > > high-security.  Neither of my boards are HS parts.  They are both GP.
> > > 
> > > N900 is HS device, but I guess that should be caused by GP vs HS
> > > difference. Working i2c bus 0 and non-working i2c bus 1 could not be
> > > caused by GP vs HS difference. Also I guess that omap hs mmc would be
> > > same on GP and HS boards.
> > ...
> > > > > Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> > > > > it returned error.
> > > > > 
> > > > > If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> > > > > and basically U-Boot stopped responding.
> > > > > 
> > > > > So by above observation it looks like I2C bus num 1 does not work, but
> > > > > I2C bus num 0 works fine.
> > > > > 
> > > > > Do I need to call i2c_probe(...) before calling i2c_write(...)?
> > > > > 
> > > > > And is something special needed for initializing omap i2c bus num 1?
> > > > > Because from my above observation it looks like that something is
> > > > > missing for bus 1 which in older u-boot version was not needed.
> > 
> > Now I was able to find commit which is causing above i2c problems:
> > "Check if pads/pull-ups of bus are properly configured"
> > 
> > It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
> > 
> >      OMAP24xx I2C: Add support for set-speed
> >      Adds support for set-speed on the OMAP24xx I2C Adapter.
> >      Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
> >      Otherwise on a subsequent call the transfer of last byte from the
> >      predecessor is aborted and therefore lost. For exmaple when
> >      i2c_write(...) is followed by a i2c_setspeed(...) (which has to
> >      deactivate and activate master for changing psc,...).
> >      Minor cosmetical changes.
> >      Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
> >      Cc: Heiko Schocher <hs@denx.de>
> > 
> > U-Boot version prior this command does not report those i2c errors.
> > 
> > Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
> > Nokia N900?
> 
> Hard to say here anything useful, as I do not have the hardware...
> 
> The above commit changes:
> 
> -               udelay(I2C_WAIT);
> +               udelay(adap->waitdelay);
> 
> May you can check, if adap->waitdelay is the same as I2C_WAIT ?

Yes, it is the same value.

Anyway, I have deeply looked at that commit again and it just adds
support for omap24_i2c_setspeed and into omap24_i2c_write adds following
change:

@@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
 			goto wr_exit;
 		}
 	}
+	/*
+	 * poll ARDY bit for making sure that last byte really has been
+	 * transferred on the bus.
+	 */
+	do {
+		status = wait_for_event(adap);
+	} while (!(status & I2C_STAT_ARDY) && timeout--);
+	if (timeout <= 0)
+		printf("i2c_write: timed out writig last byte!\n");
 
 wr_exit:
 	flush_fifo(adap);

And this change is causing that non-functional i2c bus.

I applied revert of above change on top of the master u-boot branch and
i2c bus num 1 (second) started working on N900 hw:

diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 0af4e333c4..a49cf89712 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem *i2c_base, int ip_rev, int waitdelay,
 		}
 	}
 
-	/*
-	 * poll ARDY bit for making sure that last byte really has been
-	 * transferred on the bus.
-	 */
-	do {
-		status = wait_for_event(i2c_base, ip_rev, waitdelay);
-	} while (!(status & I2C_STAT_ARDY) && timeout--);
-	if (timeout <= 0)
-		printf("i2c_write: timed out writig last byte!\n");
-
 wr_exit:
 	flush_fifo(i2c_base, ip_rev);
 	omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);

I have looked into i2c-omap.c linux kernel driver and its transfer
function does not have any such code for waiting ARDY bit.

Why it is there? I have not able to find any information and that
comment is strange... it looks like it was incomplete/broken? workaround
about other issue.

As you can see in log,@the first call status flags contains value
0x0100 and on all other calls it contains just 0x000 status flags.

Therefore ARDY bit is never set, but i2c transfer works fine.

> bye,
> Heiko
> -- 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Heiko Schocher]

Hello Pali,

sorry for late response ...

Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>> Hello Pali,
>>
>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>
>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>
>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>>>>>>>> problem.
>>>>>>>>>>>
>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot loop.
>>>>>>>>>>>
>>>>>>>>>>> I do not have serial console for Nokia N900 to debug this issue, but
>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
>>>>>>>>>>> that there is no crash and even no error in qemu emulator so I cannot
>>>>>>>>>>> debug this issue.
>>>>>>>>>>>
>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in rx51.c. On real
>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>
>>>>>>>>>>>     Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>     Timed out in wait_for_event: status=0000
>>>>>>>>>>>
>>>>>>>>>>> When I commented that few lines all these messages disappeared. So
>>>>>>>>>>> problem is with OMAP I2C.
>>> ...
>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, could somebody
>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>
>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot to correctly
>>>>>>>>>>> work?
>>>>>>>>>>>
>>>>>>>>>>> Maybe I will try to find some time to git bisect which change broke
>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>
>>>>>>>>>> Took latest u-boot master, applied patches and this is the result on
>>>>>>>>>> serial (first part is NOLO booting, I think that can be ignored) [1].
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
>>>>>>>>>>
>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>> I2C:   ready
>>>>>>>>>> DRAM:  256 MiB
>>>>>>>>>> NAND:  0 Bytes
>>>>>>>>>
>>>>>>>>> Looks like that something with NAND is broken.
>>
>> The board code in U-Boot is in a very old state... :-(

:-(

>>>>>>>>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>> In:    vga
>>>>>>>>>> Out:   vga
>>>>>>>>>> Err:   vga
>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>
>>>>>>>>> These i2c errors are caused by
>>>>>>>>>
>>>>>>>>>         /* reset lp5523 led */
>>>>>>>>>         i2c_set_bus_num(1);
>>
>> deprecated ... the board code needs cleanup ...

Yes, my first thought too!

This board needs a complete cleanup.

> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
> still there...

Ok.

>>>>>>>>>         state = 0xff;
>>>>>>>>>         i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>         i2c_set_bus_num(0);
>>>>>>>>>
>>>>>>>>> Is there anything which needs to be done to initialize i2c bus 1?
>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>
>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git version from
>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>
>>>>>>>> On on internet forums I see these error messages also from other OMAP3
>>>>>>>> board, e.g. beagle board.
>>>>>>>>
>>>>>>>> Has somebody some working OMAP3 board? And can test if it works with
>>>>>>>> recent version of U-Boot? I guess that above i2c problem would happen
>>>>>>>> also on other OMAP3 boards.
>>>>>>>
>>>>>>> There was a conversion a while ago to dm_i2c, and I converted my board
>>>>>>> to support using the device tree during the SPL phase, and whenever I
>>>>>>> am aware any driver has driver model (DM) support, I try to convert my
>>>>>>> board.
>>>>>>>
>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
>>>>>>
>>>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>>>> problem. N900 does not use driver model.
>>>>>
>>>>> i have an OMAP3530 which is basically a 3430, and it works too.  I am
>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>> high-security.  Neither of my boards are HS parts.  They are both GP.
>>>>
>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>>>> caused by GP vs HS difference. Also I guess that omap hs mmc would be
>>>> same on GP and HS boards.
>>> ...
>>>>>> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
>>>>>> it returned error.
>>>>>>
>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
>>>>>> and basically U-Boot stopped responding.
>>>>>>
>>>>>> So by above observation it looks like I2C bus num 1 does not work, but
>>>>>> I2C bus num 0 works fine.
>>>>>>
>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>
>>>>>> And is something special needed for initializing omap i2c bus num 1?
>>>>>> Because from my above observation it looks like that something is
>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>
>>> Now I was able to find commit which is causing above i2c problems:
>>> "Check if pads/pull-ups of bus are properly configured"
>>>
>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>
>>>       OMAP24xx I2C: Add support for set-speed
>>>       Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>       Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
>>>       Otherwise on a subsequent call the transfer of last byte from the
>>>       predecessor is aborted and therefore lost. For exmaple when
>>>       i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>>>       deactivate and activate master for changing psc,...).
>>>       Minor cosmetical changes.
>>>       Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>       Cc: Heiko Schocher <hs@denx.de>
>>>
>>> U-Boot version prior this command does not report those i2c errors.
>>>
>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
>>> Nokia N900?
>>
>> Hard to say here anything useful, as I do not have the hardware...
>>
>> The above commit changes:
>>
>> -               udelay(I2C_WAIT);
>> +               udelay(adap->waitdelay);
>>
>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
> 
> Yes, it is the same value.

Ok, fine.

> Anyway, I have deeply looked at that commit again and it just adds
> support for omap24_i2c_setspeed and into omap24_i2c_write adds following
> change:
> 
> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
>   			goto wr_exit;
>   		}
>   	}
> +	/*
> +	 * poll ARDY bit for making sure that last byte really has been
> +	 * transferred on the bus.
> +	 */
> +	do {
> +		status = wait_for_event(adap);
> +	} while (!(status & I2C_STAT_ARDY) && timeout--);
> +	if (timeout <= 0)
> +		printf("i2c_write: timed out writig last byte!\n");
>   
>   wr_exit:
>   	flush_fifo(adap);
> 
> And this change is causing that non-functional i2c bus.

Ok, this part definetely changes behaviour in timing...

> I applied revert of above change on top of the master u-boot branch and
> i2c bus num 1 (second) started working on N900 hw:
> 
> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
> index 0af4e333c4..a49cf89712 100644
> --- a/drivers/i2c/omap24xx_i2c.c
> +++ b/drivers/i2c/omap24xx_i2c.c
> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem *i2c_base, int ip_rev, int waitdelay,
>   		}
>   	}
>   
> -	/*
> -	 * poll ARDY bit for making sure that last byte really has been
> -	 * transferred on the bus.
> -	 */
> -	do {
> -		status = wait_for_event(i2c_base, ip_rev, waitdelay);
> -	} while (!(status & I2C_STAT_ARDY) && timeout--);
> -	if (timeout <= 0)
> -		printf("i2c_write: timed out writig last byte!\n");
> -
>   wr_exit:
>   	flush_fifo(i2c_base, ip_rev);
>   	omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
> 
> I have looked into i2c-omap.c linux kernel driver and its transfer
> function does not have any such code for waiting ARDY bit.

Ok...

> Why it is there? I have not able to find any information and that
> comment is strange... it looks like it was incomplete/broken? workaround
> about other issue.

Hmm.. ARDY bit means:
"""
The current transaction is finished and the module registers
can be accessed.
"""

Seems not to bad to me to check this bit! ... but may missing
on transaction start some prerequisite is missing for triggering
this bit? And so, this additional check only leads in a loop
going into timeout?

> As you can see in log, at the first call status flags contains value
> 0x0100 and on all other calls it contains just 0x000 status flags.
> 
> Therefore ARDY bit is never set, but i2c transfer works fine.

Hmm... so the question why does this bit not pop up on transfer
end?

I just can speculate that adding this polling ARDY bit loop
changes the timing... and fixed an underlying bug, yes...

but if this bit never pop up, there must come the printf
"i2c_write: timed out writig last byte!" for each i2c transfer.

Hannes may you can check if this is the case for you?

why does nobody claimed that this message pops up in the last 5 years?

or reverse asked, why does this bit may not pop up for you Pali?

I have not yet time to check this... also I am unsure if I have a hw
where I can try ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Pali Rohár]

On Wednesday 28 October 2020 06:42:39 Heiko Schocher wrote:
> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
> > On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
> > > Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
> > > > On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
> > > > > On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
> > > > > > On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > > > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > > > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > > > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > > > > > > In:    vga
> > > > > > > > > > > Out:   vga
> > > > > > > > > > > Err:   vga
> > > > > > > > > > > Timed out in wait_for_event: status=0100
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > > > > > > i2c_write: timed out writig last byte!
...
> > > > Now I was able to find commit which is causing above i2c problems:
> > > > "Check if pads/pull-ups of bus are properly configured"
> > > > 
> > > > It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
> > > > 
> > > >       OMAP24xx I2C: Add support for set-speed
> > > >       Adds support for set-speed on the OMAP24xx I2C Adapter.
> > > >       Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
> > > >       Otherwise on a subsequent call the transfer of last byte from the
> > > >       predecessor is aborted and therefore lost. For exmaple when
> > > >       i2c_write(...) is followed by a i2c_setspeed(...) (which has to
> > > >       deactivate and activate master for changing psc,...).
> > > >       Minor cosmetical changes.
> > > >       Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
> > > >       Cc: Heiko Schocher <hs@denx.de>
> > > > 
> > > > U-Boot version prior this command does not report those i2c errors.
...
> > I applied revert of above change on top of the master u-boot branch and
> > i2c bus num 1 (second) started working on N900 hw:
> > 
> > diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
> > index 0af4e333c4..a49cf89712 100644
> > --- a/drivers/i2c/omap24xx_i2c.c
> > +++ b/drivers/i2c/omap24xx_i2c.c
> > @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem *i2c_base, int ip_rev, int waitdelay,
> >   		}
> >   	}
> > -	/*
> > -	 * poll ARDY bit for making sure that last byte really has been
> > -	 * transferred on the bus.
> > -	 */
> > -	do {
> > -		status = wait_for_event(i2c_base, ip_rev, waitdelay);
> > -	} while (!(status & I2C_STAT_ARDY) && timeout--);
> > -	if (timeout <= 0)
> > -		printf("i2c_write: timed out writig last byte!\n");
> > -
> >   wr_exit:
> >   	flush_fifo(i2c_base, ip_rev);
> >   	omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
> > 
> > I have looked into i2c-omap.c linux kernel driver and its transfer
> > function does not have any such code for waiting ARDY bit.
> 
> Ok...
> 
> > Why it is there? I have not able to find any information and that
> > comment is strange... it looks like it was incomplete/broken? workaround
> > about other issue.
> 
> Hmm.. ARDY bit means:
> """
> The current transaction is finished and the module registers
> can be accessed.
> """
> 
> Seems not to bad to me to check this bit! ... but may missing
> on transaction start some prerequisite is missing for triggering
> this bit? And so, this additional check only leads in a loop
> going into timeout?
> 
> > As you can see in log, at the first call status flags contains value
> > 0x0100 and on all other calls it contains just 0x000 status flags.
> > 
> > Therefore ARDY bit is never set, but i2c transfer works fine.
> 
> Hmm... so the question why does this bit not pop up on transfer
> end?

I do not know. I even do not have documentation for this i2c bus IP.
More suspicious is that this happens only for bus num 1.

Bus num 0 does not cause any issue and is working with and also without
that patch.

> I just can speculate that adding this polling ARDY bit loop
> changes the timing... and fixed an underlying bug, yes...
> 
> but if this bit never pop up, there must come the printf
> "i2c_write: timed out writig last byte!" for each i2c transfer.

Yes, it is for every bus num 1 transfer. But in N900 code there is just
one write on i2c bus 1 (to reset LED). All other devices which are
accessed from U-Boot on N900 are on i2c bus 0.

> Hannes may you can check if this is the case for you?
> 
> why does nobody claimed that this message pops up in the last 5 years?
> 
> or reverse asked, why does this bit may not pop up for you Pali?

Nokia N900 is Omap3430 HS device. I do not know how many people are
using latest U-Boot on HS devices and maybe Omap3430 has some i2c bugs?

But my main question is, why kernel's i2c driver does not do that check
for ARDY bit? And U-Boot is doing it?

> I have not yet time to check this... also I am unsure if I have a hw
> where I can try ...
> 
> bye,
> Heiko
> -- 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Ivaylo Dimitrov]

Hi,

On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
> Hello Pali,
> 
> sorry for late response ...
> 
> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
>> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>>> Hello Pali,
>>>
>>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>>
>>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>
>>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka 
>>>>>>>>>>>>> N900).
>>>>>>>>>>>>> After these changes it is possible to run U-Boot in qemu 
>>>>>>>>>>>>> emulator again.
>>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND 
>>>>>>>>>>>>> memory without
>>>>>>>>>>>>> problem.
>>>>>>>>>>>>
>>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot 
>>>>>>>>>>>> loop.
>>>>>>>>>>>>
>>>>>>>>>>>> I do not have serial console for Nokia N900 to debug this 
>>>>>>>>>>>> issue, but
>>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. 
>>>>>>>>>>>> Problem is
>>>>>>>>>>>> that there is no crash and even no error in qemu emulator so 
>>>>>>>>>>>> I cannot
>>>>>>>>>>>> debug this issue.
>>>>>>>>>>>>
>>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in 
>>>>>>>>>>>> rx51.c. On real
>>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>>
>>>>>>>>>>>> ??? Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> ??? Timed out in wait_for_event: status=0000
>>>>>>>>>>>>
>>>>>>>>>>>> When I commented that few lines all these messages 
>>>>>>>>>>>> disappeared. So
>>>>>>>>>>>> problem is with OMAP I2C.
>>>> ...
>>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, 
>>>>>>>>>>>> could somebody
>>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>>
>>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot to 
>>>>>>>>>>>> correctly
>>>>>>>>>>>> work?
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe I will try to find some time to git bisect which 
>>>>>>>>>>>> change broke
>>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>>
>>>>>>>>>>> Took latest u-boot master, applied patches and this is the 
>>>>>>>>>>> result on
>>>>>>>>>>> serial (first part is NOLO booting, I think that can be 
>>>>>>>>>>> ignored) [1].
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 
>>>>>>>>>>> 12:15:47 +0200)
>>>>>>>>>>>
>>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>>> I2C:?? ready
>>>>>>>>>>> DRAM:? 256 MiB
>>>>>>>>>>> NAND:? 0 Bytes
>>>>>>>>>>
>>>>>>>>>> Looks like that something with NAND is broken.
>>>
>>> The board code in U-Boot is in a very old state... :-(
> 
> :-(
> 
>>>>>>>>>>> MMC:?? OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>>> In:??? vga
>>>>>>>>>>> Out:?? vga
>>>>>>>>>>> Err:?? vga
>>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>> i2c_read (addr phase): pads on bus probably not configured 
>>>>>>>>>>> (status=0x10)
>>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>>
>>>>>>>>>> These i2c errors are caused by
>>>>>>>>>>
>>>>>>>>>> ??????? /* reset lp5523 led */
>>>>>>>>>> ??????? i2c_set_bus_num(1);
>>>
>>> deprecated ... the board code needs cleanup ...
> 
> Yes, my first thought too!
> 
> This board needs a complete cleanup.
> 
>> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
>> still there...
> 
> Ok.
> 
>>>>>>>>>> ??????? state = 0xff;
>>>>>>>>>> ??????? i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>> ??????? i2c_set_bus_num(0);
>>>>>>>>>>
>>>>>>>>>> Is there anything which needs to be done to initialize i2c bus 1?
>>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>>
>>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git version from
>>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>>
>>>>>>>>> On on internet forums I see these error messages also from 
>>>>>>>>> other OMAP3
>>>>>>>>> board, e.g. beagle board.
>>>>>>>>>
>>>>>>>>> Has somebody some working OMAP3 board? And can test if it works 
>>>>>>>>> with
>>>>>>>>> recent version of U-Boot? I guess that above i2c problem would 
>>>>>>>>> happen
>>>>>>>>> also on other OMAP3 boards.
>>>>>>>>
>>>>>>>> There was a conversion a while ago to dm_i2c, and I converted my 
>>>>>>>> board
>>>>>>>> to support using the device tree during the SPL phase, and 
>>>>>>>> whenever I
>>>>>>>> am aware any driver has driver model (DM) support, I try to 
>>>>>>>> convert my
>>>>>>>> board.
>>>>>>>>
>>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and it 
>>>>>>>> was working
>>>>>>>
>>>>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>>>>> problem. N900 does not use driver model.
>>>>>>
>>>>>> i have an OMAP3530 which is basically a 3430, and it works too.? I am
>>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>>> high-security.? Neither of my boards are HS parts.? They are both GP.
>>>>>
>>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>>>>> caused by GP vs HS difference. Also I guess that omap hs mmc would be
>>>>> same on GP and HS boards.
>>>> ...
>>>>>>> Before calling i2c_write(0x32, ...) I tried to call 
>>>>>>> i2c_probe(0x32) and
>>>>>>> it returned error.
>>>>>>>
>>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of 
>>>>>>> errors
>>>>>>> and basically U-Boot stopped responding.
>>>>>>>
>>>>>>> So by above observation it looks like I2C bus num 1 does not 
>>>>>>> work, but
>>>>>>> I2C bus num 0 works fine.
>>>>>>>
>>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>>
>>>>>>> And is something special needed for initializing omap i2c bus num 1?
>>>>>>> Because from my above observation it looks like that something is
>>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>>
>>>> Now I was able to find commit which is causing above i2c problems:
>>>> "Check if pads/pull-ups of bus are properly configured"
>>>>
>>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>>
>>>> ????? OMAP24xx I2C: Add support for set-speed
>>>> ????? Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>> ????? Changes to omap24_i2c_write(...) for polling ARDY Bit from 
>>>> IRQ-Status.
>>>> ????? Otherwise on a subsequent call the transfer of last byte from the
>>>> ????? predecessor is aborted and therefore lost. For exmaple when
>>>> ????? i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>>>> ????? deactivate and activate master for changing psc,...).
>>>> ????? Minor cosmetical changes.
>>>> ????? Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>> ????? Cc: Heiko Schocher <hs@denx.de>
>>>>
>>>> U-Boot version prior this command does not report those i2c errors.
>>>>
>>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
>>>> Nokia N900?
>>>
>>> Hard to say here anything useful, as I do not have the hardware...
>>>
>>> The above commit changes:
>>>
>>> -?????????????? udelay(I2C_WAIT);
>>> +?????????????? udelay(adap->waitdelay);
>>>
>>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
>>
>> Yes, it is the same value.
> 
> Ok, fine.
> 
>> Anyway, I have deeply looked at that commit again and it just adds
>> support for omap24_i2c_setspeed and into omap24_i2c_write adds following
>> change:
>>
>> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter 
>> *adap, uchar chip, uint addr,
>> ????????????? goto wr_exit;
>> ????????? }
>> ????? }
>> +??? /*
>> +???? * poll ARDY bit for making sure that last byte really has been
>> +???? * transferred on the bus.
>> +???? */
>> +??? do {
>> +??????? status = wait_for_event(adap);
>> +??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>> +??? if (timeout <= 0)
>> +??????? printf("i2c_write: timed out writig last byte!\n");
>> ? wr_exit:
>> ????? flush_fifo(adap);
>>
>> And this change is causing that non-functional i2c bus.
> 
> Ok, this part definetely changes behaviour in timing...
> 
>> I applied revert of above change on top of the master u-boot branch and
>> i2c bus num 1 (second) started working on N900 hw:
>>
>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>> index 0af4e333c4..a49cf89712 100644
>> --- a/drivers/i2c/omap24xx_i2c.c
>> +++ b/drivers/i2c/omap24xx_i2c.c
>> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem 
>> *i2c_base, int ip_rev, int waitdelay,
>> ????????? }
>> ????? }
>> -??? /*
>> -???? * poll ARDY bit for making sure that last byte really has been
>> -???? * transferred on the bus.
>> -???? */
>> -??? do {
>> -??????? status = wait_for_event(i2c_base, ip_rev, waitdelay);
>> -??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>> -??? if (timeout <= 0)
>> -??????? printf("i2c_write: timed out writig last byte!\n");
>> -
>> ? wr_exit:
>> ????? flush_fifo(i2c_base, ip_rev);
>> ????? omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
>>
>> I have looked into i2c-omap.c linux kernel driver and its transfer
>> function does not have any such code for waiting ARDY bit.
> 

Correct, but this waiting seems to be described in the TRM (see Figure 
18-46 and Figure 18-47), albeit for the polling mode. Though, in general 
flow diagrams (Figure 18-29 and Figure 18-31), there is no such loop.

However, by looking to __omap24_i2c_init(), it is not clear to me what 
mode uboot uses as it enables almost all interrupt bits in 
OMAP_I2C_IE_REG and loops waiting for events at the same time. Could 
someone confirm if uboot uses interrupt or polling mode? As this changes 
the things in regards to ARDY bit a lot, IIUC.

> Ok...
> 
>> Why it is there? I have not able to find any information and that
>> comment is strange... it looks like it was incomplete/broken? workaround
>> about other issue.
> 
> Hmm.. ARDY bit means:
> """
> The current transaction is finished and the module registers
> can be accessed.
> """
>

But it seems there is something weird about ARDY bit, at least in 
interrupt mode, see linux kernel commits cb527ede1b and 4cdbf7d346. So 
it seems ARDY bit shall be cleared twice.

> Seems not to bad to me to check this bit! ... but may missing
> on transaction start some prerequisite is missing for triggering
> this bit? And so, this additional check only leads in a loop
> going into timeout?
> 
>> As you can see in log, at the first call status flags contains value
>> 0x0100 and on all other calls it contains just 0x000 status flags.
>>
>> Therefore ARDY bit is never set, but i2c transfer works fine.
> 

What looks wrong to me is that __omap24_i2c_init() enables all 
interrupts in OMAP_I2C_IE_REG, however, the precondition for polling 
mode according to Figure 18-29 is that all interrupts shall be disabled.

> Hmm... so the question why does this bit not pop up on transfer
> end?
> 

It seems it never pops out. Moreover, if we look at the logs, the first 
wait_for_event() seems to timeout with status=0100, that is with BF bit 
set. What looks suspicions here, is that the only bit we ever see set, 
is the bit we don't have interrupt bit enabled for.

Pali, maybe you should try to comment the code that sets interrupt bits 
in __omap24_i2c_init() (the block that starts with "if (ip_rev == 
OMAP_I2C_REV_V1)") and see if it makes any difference. Also, maybe add 
more traces in __omap24_i2c_write() to see which exactly 
wait_for_event() call times out.

> I just can speculate that adding this polling ARDY bit loop
> changes the timing... and fixed an underlying bug, yes...
> 
> but if this bit never pop up, there must come the printf
> "i2c_write: timed out writig last byte!" for each i2c transfer.
> 
> Hannes may you can check if this is the case for you?
> 
> why does nobody claimed that this message pops up in the last 5 years?
> 
> or reverse asked, why does this bit may not pop up for you Pali?
> 
> I have not yet time to check this... also I am unsure if I have a hw
> where I can try ...
> 
> bye,
> Heiko

Regards,
Ivo

U-Boot i2c bus num 1 is broken on Nokia N900

[Heiko Schocher]

Hello Ivaylo,

Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov:
> Hi,
> 
> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
>> Hello Pali,
>>
>> sorry for late response ...
>>
>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
>>> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>>>> Hello Pali,
>>>>
>>>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>>>
>>>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>>>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot loop.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I do not have serial console for Nokia N900 to debug this issue, but
>>>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
>>>>>>>>>>>>> that there is no crash and even no error in qemu emulator so I cannot
>>>>>>>>>>>>> debug this issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in rx51.c. On real
>>>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ??? Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> ??? Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>
>>>>>>>>>>>>> When I commented that few lines all these messages disappeared. So
>>>>>>>>>>>>> problem is with OMAP I2C.
>>>>> ...
>>>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, could somebody
>>>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>>>
>>>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot to correctly
>>>>>>>>>>>>> work?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe I will try to find some time to git bisect which change broke
>>>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>>>
>>>>>>>>>>>> Took latest u-boot master, applied patches and this is the result on
>>>>>>>>>>>> serial (first part is NOLO booting, I think that can be ignored) [1].
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
>>>>>>>>>>>>
>>>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>>>> I2C:?? ready
>>>>>>>>>>>> DRAM:? 256 MiB
>>>>>>>>>>>> NAND:? 0 Bytes
>>>>>>>>>>>
>>>>>>>>>>> Looks like that something with NAND is broken.
>>>>
>>>> The board code in U-Boot is in a very old state... :-(
>>
>> :-(
>>
>>>>>>>>>>>> MMC:?? OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>>>> In:??? vga
>>>>>>>>>>>> Out:?? vga
>>>>>>>>>>>> Err:?? vga
>>>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
>>>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>>>
>>>>>>>>>>> These i2c errors are caused by
>>>>>>>>>>>
>>>>>>>>>>> ??????? /* reset lp5523 led */
>>>>>>>>>>> ??????? i2c_set_bus_num(1);
>>>>
>>>> deprecated ... the board code needs cleanup ...
>>
>> Yes, my first thought too!
>>
>> This board needs a complete cleanup.
>>
>>> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
>>> still there...
>>
>> Ok.
>>
>>>>>>>>>>> ??????? state = 0xff;
>>>>>>>>>>> ??????? i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>>> ??????? i2c_set_bus_num(0);
>>>>>>>>>>>
>>>>>>>>>>> Is there anything which needs to be done to initialize i2c bus 1?
>>>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>>>
>>>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git version from
>>>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>>>
>>>>>>>>>> On on internet forums I see these error messages also from other OMAP3
>>>>>>>>>> board, e.g. beagle board.
>>>>>>>>>>
>>>>>>>>>> Has somebody some working OMAP3 board? And can test if it works with
>>>>>>>>>> recent version of U-Boot? I guess that above i2c problem would happen
>>>>>>>>>> also on other OMAP3 boards.
>>>>>>>>>
>>>>>>>>> There was a conversion a while ago to dm_i2c, and I converted my board
>>>>>>>>> to support using the device tree during the SPL phase, and whenever I
>>>>>>>>> am aware any driver has driver model (DM) support, I try to convert my
>>>>>>>>> board.
>>>>>>>>>
>>>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
>>>>>>>>
>>>>>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>>>>>> problem. N900 does not use driver model.
>>>>>>>
>>>>>>> i have an OMAP3530 which is basically a 3430, and it works too.? I am
>>>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>>>> high-security.? Neither of my boards are HS parts.? They are both GP.
>>>>>>
>>>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>>>>>> caused by GP vs HS difference. Also I guess that omap hs mmc would be
>>>>>> same on GP and HS boards.
>>>>> ...
>>>>>>>> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
>>>>>>>> it returned error.
>>>>>>>>
>>>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
>>>>>>>> and basically U-Boot stopped responding.
>>>>>>>>
>>>>>>>> So by above observation it looks like I2C bus num 1 does not work, but
>>>>>>>> I2C bus num 0 works fine.
>>>>>>>>
>>>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>>>
>>>>>>>> And is something special needed for initializing omap i2c bus num 1?
>>>>>>>> Because from my above observation it looks like that something is
>>>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>>>
>>>>> Now I was able to find commit which is causing above i2c problems:
>>>>> "Check if pads/pull-ups of bus are properly configured"
>>>>>
>>>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>>>
>>>>> ????? OMAP24xx I2C: Add support for set-speed
>>>>> ????? Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>>> ????? Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
>>>>> ????? Otherwise on a subsequent call the transfer of last byte from the
>>>>> ????? predecessor is aborted and therefore lost. For exmaple when
>>>>> ????? i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>>>>> ????? deactivate and activate master for changing psc,...).
>>>>> ????? Minor cosmetical changes.
>>>>> ????? Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>>> ????? Cc: Heiko Schocher <hs@denx.de>
>>>>>
>>>>> U-Boot version prior this command does not report those i2c errors.
>>>>>
>>>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
>>>>> Nokia N900?
>>>>
>>>> Hard to say here anything useful, as I do not have the hardware...
>>>>
>>>> The above commit changes:
>>>>
>>>> -?????????????? udelay(I2C_WAIT);
>>>> +?????????????? udelay(adap->waitdelay);
>>>>
>>>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
>>>
>>> Yes, it is the same value.
>>
>> Ok, fine.
>>
>>> Anyway, I have deeply looked at that commit again and it just adds
>>> support for omap24_i2c_setspeed and into omap24_i2c_write adds following
>>> change:
>>>
>>> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
>>> ????????????? goto wr_exit;
>>> ????????? }
>>> ????? }
>>> +??? /*
>>> +???? * poll ARDY bit for making sure that last byte really has been
>>> +???? * transferred on the bus.
>>> +???? */
>>> +??? do {
>>> +??????? status = wait_for_event(adap);
>>> +??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>> +??? if (timeout <= 0)
>>> +??????? printf("i2c_write: timed out writig last byte!\n");
>>> ? wr_exit:
>>> ????? flush_fifo(adap);
>>>
>>> And this change is causing that non-functional i2c bus.
>>
>> Ok, this part definetely changes behaviour in timing...
>>
>>> I applied revert of above change on top of the master u-boot branch and
>>> i2c bus num 1 (second) started working on N900 hw:
>>>
>>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>>> index 0af4e333c4..a49cf89712 100644
>>> --- a/drivers/i2c/omap24xx_i2c.c
>>> +++ b/drivers/i2c/omap24xx_i2c.c
>>> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem *i2c_base, int ip_rev, int 
>>> waitdelay,
>>> ????????? }
>>> ????? }
>>> -??? /*
>>> -???? * poll ARDY bit for making sure that last byte really has been
>>> -???? * transferred on the bus.
>>> -???? */
>>> -??? do {
>>> -??????? status = wait_for_event(i2c_base, ip_rev, waitdelay);
>>> -??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>> -??? if (timeout <= 0)
>>> -??????? printf("i2c_write: timed out writig last byte!\n");
>>> -
>>> ? wr_exit:
>>> ????? flush_fifo(i2c_base, ip_rev);
>>> ????? omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
>>>
>>> I have looked into i2c-omap.c linux kernel driver and its transfer
>>> function does not have any such code for waiting ARDY bit.
>>
> 
> Correct, but this waiting seems to be described in the TRM (see Figure 18-46 and Figure 18-47), 
> albeit for the polling mode. Though, in general flow diagrams (Figure 18-29 and Figure 18-31), there 
> is no such loop.

Could you provide a link to the TRM?

> However, by looking to __omap24_i2c_init(), it is not clear to me what mode uboot uses as it enables 
> almost all interrupt bits in OMAP_I2C_IE_REG and loops waiting for events at the same time. Could 
> someone confirm if uboot uses interrupt or polling mode? As this changes the things in regards to 
> ARDY bit a lot, IIUC.

I think, u-boot only polls the registers, while enabling all
interrupt bits ...

>> Ok...
>>
>>> Why it is there? I have not able to find any information and that
>>> comment is strange... it looks like it was incomplete/broken? workaround
>>> about other issue.
>>
>> Hmm.. ARDY bit means:
>> """
>> The current transaction is finished and the module registers
>> can be accessed.
>> """
>>
> 
> But it seems there is something weird about ARDY bit, at least in interrupt mode, see linux kernel 
> commits cb527ede1b and 4cdbf7d346. So it seems ARDY bit shall be cleared twice.

Hmm.. yes.

>> Seems not to bad to me to check this bit! ... but may missing
>> on transaction start some prerequisite is missing for triggering
>> this bit? And so, this additional check only leads in a loop
>> going into timeout?
>>
>>> As you can see in log, at the first call status flags contains value
>>> 0x0100 and on all other calls it contains just 0x000 status flags.
>>>
>>> Therefore ARDY bit is never set, but i2c transfer works fine.
>>
> 
> What looks wrong to me is that __omap24_i2c_init() enables all interrupts in OMAP_I2C_IE_REG, 
> however, the precondition for polling mode according to Figure 18-29 is that all interrupts shall be 
> disabled.
> 
>> Hmm... so the question why does this bit not pop up on transfer
>> end?
>>
> 
> It seems it never pops out. Moreover, if we look at the logs, the first wait_for_event() seems to 

yes.

> timeout with status=0100, that is with BF bit set. What looks suspicions here, is that the only bit 
> we ever see set, is the bit we don't have interrupt bit enabled for.
> 
> Pali, maybe you should try to comment the code that sets interrupt bits in __omap24_i2c_init() (the 
> block that starts with "if (ip_rev == OMAP_I2C_REV_V1)") and see if it makes any difference. Also, 
> maybe add more traces in __omap24_i2c_write() to see which exactly wait_for_event() call times out.

May worth a try.

More mystically is, that it works fine for Pali on bus 0 but
makes problems on bus 1 ... !?

Pali: Do you have also on bus 0 i2c writes?

>> I just can speculate that adding this polling ARDY bit loop
>> changes the timing... and fixed an underlying bug, yes...
>>
>> but if this bit never pop up, there must come the printf
>> "i2c_write: timed out writig last byte!" for each i2c transfer.
>>
>> Hannes may you can check if this is the case for you?
>>
>> why does nobody claimed that this message pops up in the last 5 years?
>>
>> or reverse asked, why does this bit may not pop up for you Pali?
>>
>> I have not yet time to check this... also I am unsure if I have a hw
>> where I can try ...
>>
>> bye,
>> Heiko
> 
> Regards,
> Ivo
> 

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Pali Rohár]

On Thursday 29 October 2020 10:32:04 Heiko Schocher wrote:
> More mystically is, that it works fine for Pali on bus 0 but
> makes problems on bus 1 ... !?
> 
> Pali: Do you have also on bus 0 i2c writes?

Yes, there are many, search for "i2c_write" and see:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

And they works fine.

Everything is for bus 0 except that one problematic i2c write which is
for bus 1.

U-Boot i2c bus num 1 is broken on Nokia N900

[Ivaylo Dimitrov]

Hi,

On 29.10.20 ?. 11:32 ?., Heiko Schocher wrote:
> Hello Ivaylo,
> 
> Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov:
>> Hi,
>>
>> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
>>> Hello Pali,
>>>
>>> sorry for late response ...
>>>
>>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
>>>> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>>>>> Hello Pali,
>>>>>
>>>>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>>>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>>>>
>>>>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> 
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board 
>>>>>>>>>>>>>>> (aka N900).
>>>>>>>>>>>>>>> After these changes it is possible to run U-Boot in qemu 
>>>>>>>>>>>>>>> emulator again.
>>>>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or 
>>>>>>>>>>>>>>> OneNAND memory without
>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot 
>>>>>>>>>>>>>> loop.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I do not have serial console for Nokia N900 to debug this 
>>>>>>>>>>>>>> issue, but
>>>>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. 
>>>>>>>>>>>>>> Problem is
>>>>>>>>>>>>>> that there is no crash and even no error in qemu emulator 
>>>>>>>>>>>>>> so I cannot
>>>>>>>>>>>>>> debug this issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in 
>>>>>>>>>>>>>> rx51.c. On real
>>>>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ??? Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> ??? Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When I commented that few lines all these messages 
>>>>>>>>>>>>>> disappeared. So
>>>>>>>>>>>>>> problem is with OMAP I2C.
>>>>>> ...
>>>>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, 
>>>>>>>>>>>>>> could somebody
>>>>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot 
>>>>>>>>>>>>>> to correctly
>>>>>>>>>>>>>> work?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe I will try to find some time to git bisect which 
>>>>>>>>>>>>>> change broke
>>>>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Took latest u-boot master, applied patches and this is the 
>>>>>>>>>>>>> result on
>>>>>>>>>>>>> serial (first part is NOLO booting, I think that can be 
>>>>>>>>>>>>> ignored) [1].
>>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 
>>>>>>>>>>>>> 12:15:47 +0200)
>>>>>>>>>>>>>
>>>>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>>>>> I2C:?? ready
>>>>>>>>>>>>> DRAM:? 256 MiB
>>>>>>>>>>>>> NAND:? 0 Bytes
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like that something with NAND is broken.
>>>>>
>>>>> The board code in U-Boot is in a very old state... :-(
>>>
>>> :-(
>>>
>>>>>>>>>>>>> MMC:?? OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>>>>> In:??? vga
>>>>>>>>>>>>> Out:?? vga
>>>>>>>>>>>>> Err:?? vga
>>>>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>> i2c_read (addr phase): pads on bus probably not configured 
>>>>>>>>>>>>> (status=0x10)

How is that trace even possible? I built and tested u-boot here on my 
devices and I see the same message, but unless I am becoming blind, 
i2c_read() is never called from within i2c_write(). This is really 
suspicious.

>>>>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>>>>
>>>>>>>>>>>> These i2c errors are caused by
>>>>>>>>>>>>
>>>>>>>>>>>> ??????? /* reset lp5523 led */
>>>>>>>>>>>> ??????? i2c_set_bus_num(1);
>>>>>
>>>>> deprecated ... the board code needs cleanup ...
>>>
>>> Yes, my first thought too!
>>>
>>> This board needs a complete cleanup.
>>>
>>>> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
>>>> still there...
>>>
>>> Ok.
>>>
>>>>>>>>>>>> ??????? state = 0xff;
>>>>>>>>>>>> ??????? i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>>>> ??????? i2c_set_bus_num(0);
>>>>>>>>>>>>
>>>>>>>>>>>> Is there anything which needs to be done to initialize i2c 
>>>>>>>>>>>> bus 1?
>>>>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>>>>
>>>>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git version 
>>>>>>>>>>> from
>>>>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>>>>
>>>>>>>>>>> On on internet forums I see these error messages also from 
>>>>>>>>>>> other OMAP3
>>>>>>>>>>> board, e.g. beagle board.
>>>>>>>>>>>
>>>>>>>>>>> Has somebody some working OMAP3 board? And can test if it 
>>>>>>>>>>> works with
>>>>>>>>>>> recent version of U-Boot? I guess that above i2c problem 
>>>>>>>>>>> would happen
>>>>>>>>>>> also on other OMAP3 boards.
>>>>>>>>>>
>>>>>>>>>> There was a conversion a while ago to dm_i2c, and I converted 
>>>>>>>>>> my board
>>>>>>>>>> to support using the device tree during the SPL phase, and 
>>>>>>>>>> whenever I
>>>>>>>>>> am aware any driver has driver model (DM) support, I try to 
>>>>>>>>>> convert my
>>>>>>>>>> board.
>>>>>>>>>>
>>>>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and 
>>>>>>>>>> it was working
>>>>>>>>>
>>>>>>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>>>>>>> problem. N900 does not use driver model.
>>>>>>>>
>>>>>>>> i have an OMAP3530 which is basically a 3430, and it works too.  
>>>>>>>> I am
>>>>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>>>>> high-security.? Neither of my boards are HS parts.? They are 
>>>>>>>> both GP.
>>>>>>>
>>>>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>>>>>>> caused by GP vs HS difference. Also I guess that omap hs mmc 
>>>>>>> would be
>>>>>>> same on GP and HS boards.
>>>>>> ...
>>>>>>>>> Before calling i2c_write(0x32, ...) I tried to call 
>>>>>>>>> i2c_probe(0x32) and
>>>>>>>>> it returned error.
>>>>>>>>>
>>>>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of 
>>>>>>>>> errors
>>>>>>>>> and basically U-Boot stopped responding.
>>>>>>>>>
>>>>>>>>> So by above observation it looks like I2C bus num 1 does not 
>>>>>>>>> work, but
>>>>>>>>> I2C bus num 0 works fine.
>>>>>>>>>
>>>>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>>>>
>>>>>>>>> And is something special needed for initializing omap i2c bus 
>>>>>>>>> num 1?
>>>>>>>>> Because from my above observation it looks like that something is
>>>>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>>>>
>>>>>> Now I was able to find commit which is causing above i2c problems:
>>>>>> "Check if pads/pull-ups of bus are properly configured"
>>>>>>
>>>>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>>>>
>>>>>> ????? OMAP24xx I2C: Add support for set-speed
>>>>>> ????? Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>>>> ????? Changes to omap24_i2c_write(...) for polling ARDY Bit from 
>>>>>> IRQ-Status.
>>>>>> ????? Otherwise on a subsequent call the transfer of last byte 
>>>>>> from the
>>>>>> ????? predecessor is aborted and therefore lost. For exmaple when
>>>>>> ????? i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>>>>>> ????? deactivate and activate master for changing psc,...).
>>>>>> ????? Minor cosmetical changes.
>>>>>> ????? Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>>>> ????? Cc: Heiko Schocher <hs@denx.de>
>>>>>>
>>>>>> U-Boot version prior this command does not report those i2c errors.
>>>>>>
>>>>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
>>>>>> Nokia N900?
>>>>>
>>>>> Hard to say here anything useful, as I do not have the hardware...
>>>>>
>>>>> The above commit changes:
>>>>>
>>>>> -?????????????? udelay(I2C_WAIT);
>>>>> +?????????????? udelay(adap->waitdelay);
>>>>>
>>>>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
>>>>
>>>> Yes, it is the same value.
>>>
>>> Ok, fine.
>>>
>>>> Anyway, I have deeply looked at that commit again and it just adds
>>>> support for omap24_i2c_setspeed and into omap24_i2c_write adds 
>>>> following
>>>> change:
>>>>
>>>> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter 
>>>> *adap, uchar chip, uint addr,
>>>> ????????????? goto wr_exit;
>>>> ????????? }
>>>> ????? }
>>>> +??? /*
>>>> +???? * poll ARDY bit for making sure that last byte really has been
>>>> +???? * transferred on the bus.
>>>> +???? */
>>>> +??? do {
>>>> +??????? status = wait_for_event(adap);
>>>> +??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>> +??? if (timeout <= 0)
>>>> +??????? printf("i2c_write: timed out writig last byte!\n");
>>>> ? wr_exit:
>>>> ????? flush_fifo(adap);
>>>>
>>>> And this change is causing that non-functional i2c bus.
>>>
>>> Ok, this part definetely changes behaviour in timing...
>>>
>>>> I applied revert of above change on top of the master u-boot branch and
>>>> i2c bus num 1 (second) started working on N900 hw:
>>>>
>>>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>>>> index 0af4e333c4..a49cf89712 100644
>>>> --- a/drivers/i2c/omap24xx_i2c.c
>>>> +++ b/drivers/i2c/omap24xx_i2c.c
>>>> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem 
>>>> *i2c_base, int ip_rev, int waitdelay,
>>>> ????????? }
>>>> ????? }
>>>> -??? /*
>>>> -???? * poll ARDY bit for making sure that last byte really has been
>>>> -???? * transferred on the bus.
>>>> -???? */
>>>> -??? do {
>>>> -??????? status = wait_for_event(i2c_base, ip_rev, waitdelay);
>>>> -??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>> -??? if (timeout <= 0)
>>>> -??????? printf("i2c_write: timed out writig last byte!\n");
>>>> -
>>>> ? wr_exit:
>>>> ????? flush_fifo(i2c_base, ip_rev);
>>>> ????? omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
>>>>
>>>> I have looked into i2c-omap.c linux kernel driver and its transfer
>>>> function does not have any such code for waiting ARDY bit.
>>>
>>
>> Correct, but this waiting seems to be described in the TRM (see Figure 
>> 18-46 and Figure 18-47), albeit for the polling mode. Though, in 
>> general flow diagrams (Figure 18-29 and Figure 18-31), there is no 
>> such loop.
> 
> Could you provide a link to the TRM?
> 

https://www.ti.com/pdfs/wtbu/OMAP34xx_ES3.1x_PUBLIC_TRM_vZN.pdf

>> However, by looking to __omap24_i2c_init(), it is not clear to me what 
>> mode uboot uses as it enables almost all interrupt bits in 
>> OMAP_I2C_IE_REG and loops waiting for events at the same time. Could 
>> someone confirm if uboot uses interrupt or polling mode? As this 
>> changes the things in regards to ARDY bit a lot, IIUC.
> 
> I think, u-boot only polls the registers, while enabling all
> interrupt bits ...
> 
>>> Ok...
>>>
>>>> Why it is there? I have not able to find any information and that
>>>> comment is strange... it looks like it was incomplete/broken? 
>>>> workaround
>>>> about other issue.
>>>
>>> Hmm.. ARDY bit means:
>>> """
>>> The current transaction is finished and the module registers
>>> can be accessed.
>>> """
>>>
>>
>> But it seems there is something weird about ARDY bit, at least in 
>> interrupt mode, see linux kernel commits cb527ede1b and 4cdbf7d346. So 
>> it seems ARDY bit shall be cleared twice.
> 
> Hmm.. yes.
> 
>>> Seems not to bad to me to check this bit! ... but may missing
>>> on transaction start some prerequisite is missing for triggering
>>> this bit? And so, this additional check only leads in a loop
>>> going into timeout?
>>>
>>>> As you can see in log, at the first call status flags contains value
>>>> 0x0100 and on all other calls it contains just 0x000 status flags.
>>>>
>>>> Therefore ARDY bit is never set, but i2c transfer works fine.
>>>
>>
>> What looks wrong to me is that __omap24_i2c_init() enables all 
>> interrupts in OMAP_I2C_IE_REG, however, the precondition for polling 
>> mode according to Figure 18-29 is that all interrupts shall be disabled.
>>
>>> Hmm... so the question why does this bit not pop up on transfer
>>> end?
>>>
>>
>> It seems it never pops out. Moreover, if we look at the logs, the 
>> first wait_for_event() seems to 
> 
> yes.
> 
>> timeout with status=0100, that is with BF bit set. What looks 
>> suspicions here, is that the only bit we ever see set, is the bit we 
>> don't have interrupt bit enabled for.
>>
>> Pali, maybe you should try to comment the code that sets interrupt 
>> bits in __omap24_i2c_init() (the block that starts with "if (ip_rev == 
>> OMAP_I2C_REV_V1)") and see if it makes any difference. Also, maybe add 
>> more traces in __omap24_i2c_write() to see which exactly 
>> wait_for_event() call times out.
> 
> May worth a try.
> 
> More mystically is, that it works fine for Pali on bus 0 but
> makes problems on bus 1 ... !?
> 
> Pali: Do you have also on bus 0 i2c writes?
> 
>>> I just can speculate that adding this polling ARDY bit loop
>>> changes the timing... and fixed an underlying bug, yes...
>>>
>>> but if this bit never pop up, there must come the printf
>>> "i2c_write: timed out writig last byte!" for each i2c transfer.
>>>

And this is what happens, we have that once, as we write only one byte 
to bus 1.

>>> Hannes may you can check if this is the case for you?
>>>
>>> why does nobody claimed that this message pops up in the last 5 years?
>>>

I can confirm I see it on the 2 devices I tested here.

What is worse, is that writing on bus 1 does not fail every time. I 
increased I2C_TIMEOUT to 100000 (the value from the TRM) and it seems 
now after power-cycle, write succeeds almost every time, however, after 
a reset command from u-boot, it usually fails. And with that increased 
timeout,when it fails I see:

Check if pads/pull-ups of bus are properly configured
i2c_read (addr phase): pads on bus probably not configured (status=0x10)

message 5 times during the failing write.

How we end up there, is a mystery to me.

Regards,
Ivo

U-Boot i2c bus num 1 is broken on Nokia N900

[Heiko Schocher]

Hello Ivaylo,

Am 30.10.2020 um 08:00 schrieb Ivaylo Dimitrov:
> Hi,
> 
> On 29.10.20 ?. 11:32 ?., Heiko Schocher wrote:
>> Hello Ivaylo,
>>
>> Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov:
>>> Hi,
>>>
>>> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
>>>> Hello Pali,
>>>>
>>>> sorry for late response ...
>>>>
>>>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
>>>>> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>>>>>> Hello Pali,
>>>>>>
>>>>>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>>>>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>>>>>
>>>>>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>>>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>>>>>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in reboot loop.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not have serial console for Nokia N900 to debug this issue, but
>>>>>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
>>>>>>>>>>>>>>> that there is no crash and even no error in qemu emulator so I cannot
>>>>>>>>>>>>>>> debug this issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in rx51.c. On real
>>>>>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ??? Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> ??? Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I commented that few lines all these messages disappeared. So
>>>>>>>>>>>>>>> problem is with OMAP I2C.
>>>>>>> ...
>>>>>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, could somebody
>>>>>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot to correctly
>>>>>>>>>>>>>>> work?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe I will try to find some time to git bisect which change broke
>>>>>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Took latest u-boot master, applied patches and this is the result on
>>>>>>>>>>>>>> serial (first part is NOLO booting, I think that can be ignored) [1].
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>>>>>> I2C:?? ready
>>>>>>>>>>>>>> DRAM:? 256 MiB
>>>>>>>>>>>>>> NAND:? 0 Bytes
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like that something with NAND is broken.
>>>>>>
>>>>>> The board code in U-Boot is in a very old state... :-(
>>>>
>>>> :-(
>>>>
>>>>>>>>>>>>>> MMC:?? OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>>>>>> In:??? vga
>>>>>>>>>>>>>> Out:?? vga
>>>>>>>>>>>>>> Err:?? vga
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> 
> How is that trace even possible? I built and tested u-boot here on my devices and I see the same 
> message, but unless I am becoming blind, i2c_read() is never called from within i2c_write(). This is 
> really suspicious.

Puh..

> 
>>>>>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>>>>>
>>>>>>>>>>>>> These i2c errors are caused by
>>>>>>>>>>>>>
>>>>>>>>>>>>> ??????? /* reset lp5523 led */
>>>>>>>>>>>>> ??????? i2c_set_bus_num(1);
>>>>>>
>>>>>> deprecated ... the board code needs cleanup ...
>>>>
>>>> Yes, my first thought too!
>>>>
>>>> This board needs a complete cleanup.
>>>>
>>>>> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
>>>>> still there...
>>>>
>>>> Ok.
>>>>
>>>>>>>>>>>>> ??????? state = 0xff;
>>>>>>>>>>>>> ??????? i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>>>>> ??????? i2c_set_bus_num(0);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there anything which needs to be done to initialize i2c bus 1?
>>>>>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>>>>>
>>>>>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git version from
>>>>>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>>>>>
>>>>>>>>>>>> On on internet forums I see these error messages also from other OMAP3
>>>>>>>>>>>> board, e.g. beagle board.
>>>>>>>>>>>>
>>>>>>>>>>>> Has somebody some working OMAP3 board? And can test if it works with
>>>>>>>>>>>> recent version of U-Boot? I guess that above i2c problem would happen
>>>>>>>>>>>> also on other OMAP3 boards.
>>>>>>>>>>>
>>>>>>>>>>> There was a conversion a while ago to dm_i2c, and I converted my board
>>>>>>>>>>> to support using the device tree during the SPL phase, and whenever I
>>>>>>>>>>> am aware any driver has driver model (DM) support, I try to convert my
>>>>>>>>>>> board.
>>>>>>>>>>>
>>>>>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
>>>>>>>>>>
>>>>>>>>>> Ok, so it either OMAP3430 specific problem or N900 board specific
>>>>>>>>>> problem. N900 does not use driver model.
>>>>>>>>>
>>>>>>>>> i have an OMAP3530 which is basically a 3430, and it works too. I am
>>>>>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>>>>>> high-security.? Neither of my boards are HS parts.? They are both GP.
>>>>>>>>
>>>>>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>>>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could not be
>>>>>>>> caused by GP vs HS difference. Also I guess that omap hs mmc would be
>>>>>>>> same on GP and HS boards.
>>>>>>> ...
>>>>>>>>>> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
>>>>>>>>>> it returned error.
>>>>>>>>>>
>>>>>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
>>>>>>>>>> and basically U-Boot stopped responding.
>>>>>>>>>>
>>>>>>>>>> So by above observation it looks like I2C bus num 1 does not work, but
>>>>>>>>>> I2C bus num 0 works fine.
>>>>>>>>>>
>>>>>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>>>>>
>>>>>>>>>> And is something special needed for initializing omap i2c bus num 1?
>>>>>>>>>> Because from my above observation it looks like that something is
>>>>>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>>>>>
>>>>>>> Now I was able to find commit which is causing above i2c problems:
>>>>>>> "Check if pads/pull-ups of bus are properly configured"
>>>>>>>
>>>>>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>>>>>
>>>>>>> ????? OMAP24xx I2C: Add support for set-speed
>>>>>>> ????? Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>>>>> ????? Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
>>>>>>> ????? Otherwise on a subsequent call the transfer of last byte from the
>>>>>>> ????? predecessor is aborted and therefore lost. For exmaple when
>>>>>>> ????? i2c_write(...) is followed by a i2c_setspeed(...) (which has to
>>>>>>> ????? deactivate and activate master for changing psc,...).
>>>>>>> ????? Minor cosmetical changes.
>>>>>>> ????? Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>>>>> ????? Cc: Heiko Schocher <hs@denx.de>
>>>>>>>
>>>>>>> U-Boot version prior this command does not report those i2c errors.
>>>>>>>
>>>>>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on
>>>>>>> Nokia N900?
>>>>>>
>>>>>> Hard to say here anything useful, as I do not have the hardware...
>>>>>>
>>>>>> The above commit changes:
>>>>>>
>>>>>> -?????????????? udelay(I2C_WAIT);
>>>>>> +?????????????? udelay(adap->waitdelay);
>>>>>>
>>>>>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
>>>>>
>>>>> Yes, it is the same value.
>>>>
>>>> Ok, fine.
>>>>
>>>>> Anyway, I have deeply looked at that commit again and it just adds
>>>>> support for omap24_i2c_setspeed and into omap24_i2c_write adds following
>>>>> change:
>>>>>
>>>>> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
>>>>> ????????????? goto wr_exit;
>>>>> ????????? }
>>>>> ????? }
>>>>> +??? /*
>>>>> +???? * poll ARDY bit for making sure that last byte really has been
>>>>> +???? * transferred on the bus.
>>>>> +???? */
>>>>> +??? do {
>>>>> +??????? status = wait_for_event(adap);
>>>>> +??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>>> +??? if (timeout <= 0)
>>>>> +??????? printf("i2c_write: timed out writig last byte!\n");
>>>>> ? wr_exit:
>>>>> ????? flush_fifo(adap);
>>>>>
>>>>> And this change is causing that non-functional i2c bus.
>>>>
>>>> Ok, this part definetely changes behaviour in timing...
>>>>
>>>>> I applied revert of above change on top of the master u-boot branch and
>>>>> i2c bus num 1 (second) started working on N900 hw:
>>>>>
>>>>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>>>>> index 0af4e333c4..a49cf89712 100644
>>>>> --- a/drivers/i2c/omap24xx_i2c.c
>>>>> +++ b/drivers/i2c/omap24xx_i2c.c
>>>>> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem *i2c_base, int ip_rev, int 
>>>>> waitdelay,
>>>>> ????????? }
>>>>> ????? }
>>>>> -??? /*
>>>>> -???? * poll ARDY bit for making sure that last byte really has been
>>>>> -???? * transferred on the bus.
>>>>> -???? */
>>>>> -??? do {
>>>>> -??????? status = wait_for_event(i2c_base, ip_rev, waitdelay);
>>>>> -??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>>> -??? if (timeout <= 0)
>>>>> -??????? printf("i2c_write: timed out writig last byte!\n");
>>>>> -
>>>>> ? wr_exit:
>>>>> ????? flush_fifo(i2c_base, ip_rev);
>>>>> ????? omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, OMAP_I2C_STAT_REG);
>>>>>
>>>>> I have looked into i2c-omap.c linux kernel driver and its transfer
>>>>> function does not have any such code for waiting ARDY bit.
>>>>
>>>
>>> Correct, but this waiting seems to be described in the TRM (see Figure 18-46 and Figure 18-47), 
>>> albeit for the polling mode. Though, in general flow diagrams (Figure 18-29 and Figure 18-31), 
>>> there is no such loop.
>>
>> Could you provide a link to the TRM?
>>
> 
> https://www.ti.com/pdfs/wtbu/OMAP34xx_ES3.1x_PUBLIC_TRM_vZN.pdf

thanks! Seems I was blind ...

>>> However, by looking to __omap24_i2c_init(), it is not clear to me what mode uboot uses as it 
>>> enables almost all interrupt bits in OMAP_I2C_IE_REG and loops waiting for events at the same 
>>> time. Could someone confirm if uboot uses interrupt or polling mode? As this changes the things 
>>> in regards to ARDY bit a lot, IIUC.
>>
>> I think, u-boot only polls the registers, while enabling all
>> interrupt bits ...
>>
>>>> Ok...
>>>>
>>>>> Why it is there? I have not able to find any information and that
>>>>> comment is strange... it looks like it was incomplete/broken? workaround
>>>>> about other issue.
>>>>
>>>> Hmm.. ARDY bit means:
>>>> """
>>>> The current transaction is finished and the module registers
>>>> can be accessed.
>>>> """
>>>>
>>>
>>> But it seems there is something weird about ARDY bit, at least in interrupt mode, see linux 
>>> kernel commits cb527ede1b and 4cdbf7d346. So it seems ARDY bit shall be cleared twice.
>>
>> Hmm.. yes.
>>
>>>> Seems not to bad to me to check this bit! ... but may missing
>>>> on transaction start some prerequisite is missing for triggering
>>>> this bit? And so, this additional check only leads in a loop
>>>> going into timeout?
>>>>
>>>>> As you can see in log, at the first call status flags contains value
>>>>> 0x0100 and on all other calls it contains just 0x000 status flags.
>>>>>
>>>>> Therefore ARDY bit is never set, but i2c transfer works fine.
>>>>
>>>
>>> What looks wrong to me is that __omap24_i2c_init() enables all interrupts in OMAP_I2C_IE_REG, 
>>> however, the precondition for polling mode according to Figure 18-29 is that all interrupts shall 
>>> be disabled.
>>>
>>>> Hmm... so the question why does this bit not pop up on transfer
>>>> end?
>>>>
>>>
>>> It seems it never pops out. Moreover, if we look at the logs, the first wait_for_event() seems to 
>>
>> yes.
>>
>>> timeout with status=0100, that is with BF bit set. What looks suspicions here, is that the only 
>>> bit we ever see set, is the bit we don't have interrupt bit enabled for.
>>>
>>> Pali, maybe you should try to comment the code that sets interrupt bits in __omap24_i2c_init() 
>>> (the block that starts with "if (ip_rev == OMAP_I2C_REV_V1)") and see if it makes any difference. 
>>> Also, maybe add more traces in __omap24_i2c_write() to see which exactly wait_for_event() call 
>>> times out.
>>
>> May worth a try.
>>
>> More mystically is, that it works fine for Pali on bus 0 but
>> makes problems on bus 1 ... !?
>>
>> Pali: Do you have also on bus 0 i2c writes?
>>
>>>> I just can speculate that adding this polling ARDY bit loop
>>>> changes the timing... and fixed an underlying bug, yes...
>>>>
>>>> but if this bit never pop up, there must come the printf
>>>> "i2c_write: timed out writig last byte!" for each i2c transfer.
>>>>
> 
> And this is what happens, we have that once, as we write only one byte to bus 1.
> 
>>>> Hannes may you can check if this is the case for you?
>>>>
>>>> why does nobody claimed that this message pops up in the last 5 years?
>>>>
> 
> I can confirm I see it on the 2 devices I tested here.
> 
> What is worse, is that writing on bus 1 does not fail every time. I increased I2C_TIMEOUT to 100000 
> (the value from the TRM) and it seems now after power-cycle, write succeeds almost every time, 
> however, after a reset command from u-boot, it usually fails. And with that increased timeout,when 
> it fails I see:
> 
> Check if pads/pull-ups of bus are properly configured
> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> 
> message 5 times during the failing write.
> 
> How we end up there, is a mystery to me.

Yes...

Ok, on page 2671 is described when this ARDY event is triggered, so
if we wait for it, we must first check, if the prerequisite is met...

Hmm.. the ARDY bit is also for interrupt mode described, see page 2778
Figure 18-31 ... so I think it is correct to check it ... but
I do not see, why we should wait for it in a loop and print
an error if bit does not come up

But I have no time to dig into this ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot i2c bus num 1 is broken on Nokia N900

[Ivaylo Dimitrov]

On 30.10.20 ?. 9:24 ?., Heiko Schocher wrote:
> Hello Ivaylo,
> 
> Am 30.10.2020 um 08:00 schrieb Ivaylo Dimitrov:
>> Hi,
>>
>> On 29.10.20 ?. 11:32 ?., Heiko Schocher wrote:
>>> Hello Ivaylo,
>>>
>>> Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov:
>>>> Hi,
>>>>
>>>> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
>>>>> Hello Pali,
>>>>>
>>>>> sorry for late response ...
>>>>>
>>>>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
>>>>>> On Monday 27 April 2020 09:03:13 Heiko Schocher wrote:
>>>>>>> Hello Pali,
>>>>>>>
>>>>>>> Am 26.04.2020 um 01:54 schrieb Pali Roh?r:
>>>>>>>> Adding Hannes and Heiko to the loop, please look at this problem.
>>>>>>>>
>>>>>>>> On Saturday 25 April 2020 14:11:32 Pali Roh?r wrote:
>>>>>>>>> On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
>>>>>>>>>> On Sat, Apr 25, 2020 at 6:50 AM Pali Roh?r <pali@kernel.org> 
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>>>>>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>>>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 01/04/2020 00:42, Pali Roh?r wrote:
>>>>>>>>>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>>>>>>>>>> This patch series contain fixes for Nokia RX-51 board 
>>>>>>>>>>>>>>>>> (aka N900).
>>>>>>>>>>>>>>>>> After these changes it is possible to run U-Boot in 
>>>>>>>>>>>>>>>>> qemu emulator again.
>>>>>>>>>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or 
>>>>>>>>>>>>>>>>> OneNAND memory without
>>>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But on real Nokia N900 device is U-Boot crashing in 
>>>>>>>>>>>>>>>> reboot loop.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I do not have serial console for Nokia N900 to debug 
>>>>>>>>>>>>>>>> this issue, but
>>>>>>>>>>>>>>>> seems that it is related to OMAP I2C and OMAP HS MMC 
>>>>>>>>>>>>>>>> code. Problem is
>>>>>>>>>>>>>>>> that there is no crash and even no error in qemu 
>>>>>>>>>>>>>>>> emulator so I cannot
>>>>>>>>>>>>>>>> debug this issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First problem is around /* reset lp5523 led */ code in 
>>>>>>>>>>>>>>>> rx51.c. On real
>>>>>>>>>>>>>>>> N900 device it generates repeating messages:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ??? Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>>> ??? Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When I commented that few lines all these messages 
>>>>>>>>>>>>>>>> disappeared. So
>>>>>>>>>>>>>>>> problem is with OMAP I2C.
>>>>>>>> ...
>>>>>>>>>>>>>>>> I remember that somebody had serial jig for Nokia N900, 
>>>>>>>>>>>>>>>> could somebody
>>>>>>>>>>>>>>>> look at this reboot loop problem?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And any idea how should be OMAP I2C configured in U-Boot 
>>>>>>>>>>>>>>>> to correctly
>>>>>>>>>>>>>>>> work?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe I will try to find some time to git bisect which 
>>>>>>>>>>>>>>>> change broke
>>>>>>>>>>>>>>>> U-Boot on real N900 hardware.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Took latest u-boot master, applied patches and this is 
>>>>>>>>>>>>>>> the result on
>>>>>>>>>>>>>>> serial (first part is NOLO booting, I think that can be 
>>>>>>>>>>>>>>> ignored) [1].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 
>>>>>>>>>>>>>>> 12:15:47 +0200)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 
>>>>>>>>>>>>>>> MHz
>>>>>>>>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>>>>>>>>> I2C:?? ready
>>>>>>>>>>>>>>> DRAM:? 256 MiB
>>>>>>>>>>>>>>> NAND:? 0 Bytes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looks like that something with NAND is broken.
>>>>>>>
>>>>>>> The board code in U-Boot is in a very old state... :-(
>>>>>
>>>>> :-(
>>>>>
>>>>>>>>>>>>>>> MMC:?? OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>>>>>>>>> In:??? vga
>>>>>>>>>>>>>>> Out:?? vga
>>>>>>>>>>>>>>> Err:?? vga
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0100
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> Timed out in wait_for_event: status=0000
>>>>>>>>>>>>>>> Check if pads/pull-ups of bus are properly configured
>>>>>>>>>>>>>>> i2c_read (addr phase): pads on bus probably not 
>>>>>>>>>>>>>>> configured (status=0x10)
>>
>> How is that trace even possible? I built and tested u-boot here on my 
>> devices and I see the same message, but unless I am becoming blind, 
>> i2c_read() is never called from within i2c_write(). This is really 
>> suspicious.
> 
> Puh..
> 

It turned out it is WD that kicks in.

>>
>>>>>>>>>>>>>>> i2c_write: timed out writig last byte!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These i2c errors are caused by
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ??????? /* reset lp5523 led */
>>>>>>>>>>>>>> ??????? i2c_set_bus_num(1);
>>>>>>>
>>>>>>> deprecated ... the board code needs cleanup ...
>>>>>
>>>>> Yes, my first thought too!
>>>>>
>>>>> This board needs a complete cleanup.
>>>>>
>>>>>> I converted code to CONFIG_DM_I2C and nothing was changed, issue is
>>>>>> still there...
>>>>>
>>>>> Ok.
>>>>>
>>>>>>>>>>>>>> ??????? state = 0xff;
>>>>>>>>>>>>>> ??????? i2c_write(0x32, 0x3d, 1, &state, 1);
>>>>>>>>>>>>>> ??????? i2c_set_bus_num(0);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there anything which needs to be done to initialize i2c 
>>>>>>>>>>>>>> bus 1?
>>>>>>>>>>>>>> Because this code is working fine on older U-Boot version.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Above code worked fine for U-Boot 2013.04, but in git 
>>>>>>>>>>>>> version from
>>>>>>>>>>>>> January 2015 it prints above error messages.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On on internet forums I see these error messages also from 
>>>>>>>>>>>>> other OMAP3
>>>>>>>>>>>>> board, e.g. beagle board.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Has somebody some working OMAP3 board? And can test if it 
>>>>>>>>>>>>> works with
>>>>>>>>>>>>> recent version of U-Boot? I guess that above i2c problem 
>>>>>>>>>>>>> would happen
>>>>>>>>>>>>> also on other OMAP3 boards.
>>>>>>>>>>>>
>>>>>>>>>>>> There was a conversion a while ago to dm_i2c, and I 
>>>>>>>>>>>> converted my board
>>>>>>>>>>>> to support using the device tree during the SPL phase, and 
>>>>>>>>>>>> whenever I
>>>>>>>>>>>> am aware any driver has driver model (DM) support, I try to 
>>>>>>>>>>>> convert my
>>>>>>>>>>>> board.
>>>>>>>>>>>>
>>>>>>>>>>>> I have a DM3730 and the last check I did was 2020.04-rc1, 
>>>>>>>>>>>> and it was working
>>>>>>>>>>>
>>>>>>>>>>> Ok, so it either OMAP3430 specific problem or N900 board 
>>>>>>>>>>> specific
>>>>>>>>>>> problem. N900 does not use driver model.
>>>>>>>>>>
>>>>>>>>>> i have an OMAP3530 which is basically a 3430, and it works 
>>>>>>>>>> too. I am
>>>>>>>>>> guessing the issue is unique to the N900 or the fact that it's
>>>>>>>>>> high-security.? Neither of my boards are HS parts.? They are 
>>>>>>>>>> both GP.
>>>>>>>>>
>>>>>>>>> N900 is HS device, but I guess that should be caused by GP vs HS
>>>>>>>>> difference. Working i2c bus 0 and non-working i2c bus 1 could 
>>>>>>>>> not be
>>>>>>>>> caused by GP vs HS difference. Also I guess that omap hs mmc 
>>>>>>>>> would be
>>>>>>>>> same on GP and HS boards.
>>>>>>>> ...
>>>>>>>>>>> Before calling i2c_write(0x32, ...) I tried to call 
>>>>>>>>>>> i2c_probe(0x32) and
>>>>>>>>>>> it returned error.
>>>>>>>>>>>
>>>>>>>>>>> If I tried to call "i2c dev 1" in U-Boot console, I got tons 
>>>>>>>>>>> of errors
>>>>>>>>>>> and basically U-Boot stopped responding.
>>>>>>>>>>>
>>>>>>>>>>> So by above observation it looks like I2C bus num 1 does not 
>>>>>>>>>>> work, but
>>>>>>>>>>> I2C bus num 0 works fine.
>>>>>>>>>>>
>>>>>>>>>>> Do I need to call i2c_probe(...) before calling i2c_write(...)?
>>>>>>>>>>>
>>>>>>>>>>> And is something special needed for initializing omap i2c bus 
>>>>>>>>>>> num 1?
>>>>>>>>>>> Because from my above observation it looks like that 
>>>>>>>>>>> something is
>>>>>>>>>>> missing for bus 1 which in older u-boot version was not needed.
>>>>>>>>
>>>>>>>> Now I was able to find commit which is causing above i2c problems:
>>>>>>>> "Check if pads/pull-ups of bus are properly configured"
>>>>>>>>
>>>>>>>> It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
>>>>>>>>
>>>>>>>> ????? OMAP24xx I2C: Add support for set-speed
>>>>>>>> ????? Adds support for set-speed on the OMAP24xx I2C Adapter.
>>>>>>>> ????? Changes to omap24_i2c_write(...) for polling ARDY Bit from 
>>>>>>>> IRQ-Status.
>>>>>>>> ????? Otherwise on a subsequent call the transfer of last byte 
>>>>>>>> from the
>>>>>>>> ????? predecessor is aborted and therefore lost. For exmaple when
>>>>>>>> ????? i2c_write(...) is followed by a i2c_setspeed(...) (which 
>>>>>>>> has to
>>>>>>>> ????? deactivate and activate master for changing psc,...).
>>>>>>>> ????? Minor cosmetical changes.
>>>>>>>> ????? Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
>>>>>>>> ????? Cc: Heiko Schocher <hs@denx.de>
>>>>>>>>
>>>>>>>> U-Boot version prior this command does not report those i2c errors.
>>>>>>>>
>>>>>>>> Hannes, any idea how your patch could broke omap i2c i2c bus num 
>>>>>>>> 1 on
>>>>>>>> Nokia N900?
>>>>>>>
>>>>>>> Hard to say here anything useful, as I do not have the hardware...
>>>>>>>
>>>>>>> The above commit changes:
>>>>>>>
>>>>>>> -?????????????? udelay(I2C_WAIT);
>>>>>>> +?????????????? udelay(adap->waitdelay);
>>>>>>>
>>>>>>> May you can check, if adap->waitdelay is the same as I2C_WAIT ?
>>>>>>
>>>>>> Yes, it is the same value.
>>>>>
>>>>> Ok, fine.
>>>>>
>>>>>> Anyway, I have deeply looked at that commit again and it just adds
>>>>>> support for omap24_i2c_setspeed and into omap24_i2c_write adds 
>>>>>> following
>>>>>> change:
>>>>>>
>>>>>> @@ -464,6 +502,15 @@ static int omap24_i2c_write(struct 
>>>>>> i2c_adapter *adap, uchar chip, uint addr,
>>>>>> ????????????? goto wr_exit;
>>>>>> ????????? }
>>>>>> ????? }
>>>>>> +??? /*
>>>>>> +???? * poll ARDY bit for making sure that last byte really has been
>>>>>> +???? * transferred on the bus.
>>>>>> +???? */
>>>>>> +??? do {
>>>>>> +??????? status = wait_for_event(adap);
>>>>>> +??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>>>> +??? if (timeout <= 0)
>>>>>> +??????? printf("i2c_write: timed out writig last byte!\n");
>>>>>> ? wr_exit:
>>>>>> ????? flush_fifo(adap);
>>>>>>
>>>>>> And this change is causing that non-functional i2c bus.
>>>>>
>>>>> Ok, this part definetely changes behaviour in timing...
>>>>>
>>>>>> I applied revert of above change on top of the master u-boot 
>>>>>> branch and
>>>>>> i2c bus num 1 (second) started working on N900 hw:
>>>>>>
>>>>>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>>>>>> index 0af4e333c4..a49cf89712 100644
>>>>>> --- a/drivers/i2c/omap24xx_i2c.c
>>>>>> +++ b/drivers/i2c/omap24xx_i2c.c
>>>>>> @@ -820,16 +820,6 @@ static int __omap24_i2c_write(void __iomem 
>>>>>> *i2c_base, int ip_rev, int waitdelay,
>>>>>> ????????? }
>>>>>> ????? }
>>>>>> -??? /*
>>>>>> -???? * poll ARDY bit for making sure that last byte really has been
>>>>>> -???? * transferred on the bus.
>>>>>> -???? */
>>>>>> -??? do {
>>>>>> -??????? status = wait_for_event(i2c_base, ip_rev, waitdelay);
>>>>>> -??? } while (!(status & I2C_STAT_ARDY) && timeout--);
>>>>>> -??? if (timeout <= 0)
>>>>>> -??????? printf("i2c_write: timed out writig last byte!\n");
>>>>>> -
>>>>>> ? wr_exit:
>>>>>> ????? flush_fifo(i2c_base, ip_rev);
>>>>>> ????? omap_i2c_write_reg(i2c_base, ip_rev, 0xFFFF, 
>>>>>> OMAP_I2C_STAT_REG);
>>>>>>
>>>>>> I have looked into i2c-omap.c linux kernel driver and its transfer
>>>>>> function does not have any such code for waiting ARDY bit.
>>>>>
>>>>
>>>> Correct, but this waiting seems to be described in the TRM (see 
>>>> Figure 18-46 and Figure 18-47), albeit for the polling mode. Though, 
>>>> in general flow diagrams (Figure 18-29 and Figure 18-31), there is 
>>>> no such loop.
>>>
>>> Could you provide a link to the TRM?
>>>
>>
>> https://www.ti.com/pdfs/wtbu/OMAP34xx_ES3.1x_PUBLIC_TRM_vZN.pdf
> 
> thanks! Seems I was blind ...
> 
>>>> However, by looking to __omap24_i2c_init(), it is not clear to me 
>>>> what mode uboot uses as it enables almost all interrupt bits in 
>>>> OMAP_I2C_IE_REG and loops waiting for events at the same time. Could 
>>>> someone confirm if uboot uses interrupt or polling mode? As this 
>>>> changes the things in regards to ARDY bit a lot, IIUC.
>>>
>>> I think, u-boot only polls the registers, while enabling all
>>> interrupt bits ...
>>>
>>>>> Ok...
>>>>>
>>>>>> Why it is there? I have not able to find any information and that
>>>>>> comment is strange... it looks like it was incomplete/broken? 
>>>>>> workaround
>>>>>> about other issue.
>>>>>
>>>>> Hmm.. ARDY bit means:
>>>>> """
>>>>> The current transaction is finished and the module registers
>>>>> can be accessed.
>>>>> """
>>>>>
>>>>
>>>> But it seems there is something weird about ARDY bit, at least in 
>>>> interrupt mode, see linux kernel commits cb527ede1b and 4cdbf7d346. 
>>>> So it seems ARDY bit shall be cleared twice.
>>>
>>> Hmm.. yes.
>>>
>>>>> Seems not to bad to me to check this bit! ... but may missing
>>>>> on transaction start some prerequisite is missing for triggering
>>>>> this bit? And so, this additional check only leads in a loop
>>>>> going into timeout?
>>>>>
>>>>>> As you can see in log, at the first call status flags contains value
>>>>>> 0x0100 and on all other calls it contains just 0x000 status flags.
>>>>>>
>>>>>> Therefore ARDY bit is never set, but i2c transfer works fine.
>>>>>
>>>>
>>>> What looks wrong to me is that __omap24_i2c_init() enables all 
>>>> interrupts in OMAP_I2C_IE_REG, however, the precondition for polling 
>>>> mode according to Figure 18-29 is that all interrupts shall be 
>>>> disabled.
>>>>
>>>>> Hmm... so the question why does this bit not pop up on transfer
>>>>> end?
>>>>>
>>>>
>>>> It seems it never pops out. Moreover, if we look at the logs, the 
>>>> first wait_for_event() seems to 
>>>
>>> yes.
>>>
>>>> timeout with status=0100, that is with BF bit set. What looks 
>>>> suspicions here, is that the only bit we ever see set, is the bit we 
>>>> don't have interrupt bit enabled for.
>>>>
>>>> Pali, maybe you should try to comment the code that sets interrupt 
>>>> bits in __omap24_i2c_init() (the block that starts with "if (ip_rev 
>>>> == OMAP_I2C_REV_V1)") and see if it makes any difference. Also, 
>>>> maybe add more traces in __omap24_i2c_write() to see which exactly 
>>>> wait_for_event() call times out.
>>>
>>> May worth a try.
>>>
>>> More mystically is, that it works fine for Pali on bus 0 but
>>> makes problems on bus 1 ... !?
>>>
>>> Pali: Do you have also on bus 0 i2c writes?
>>>
>>>>> I just can speculate that adding this polling ARDY bit loop
>>>>> changes the timing... and fixed an underlying bug, yes...
>>>>>
>>>>> but if this bit never pop up, there must come the printf
>>>>> "i2c_write: timed out writig last byte!" for each i2c transfer.
>>>>>
>>
>> And this is what happens, we have that once, as we write only one byte 
>> to bus 1.
>>
>>>>> Hannes may you can check if this is the case for you?
>>>>>
>>>>> why does nobody claimed that this message pops up in the last 5 years?
>>>>>
>>
>> I can confirm I see it on the 2 devices I tested here.
>>
>> What is worse, is that writing on bus 1 does not fail every time. I 
>> increased I2C_TIMEOUT to 100000 (the value from the TRM) and it seems 
>> now after power-cycle, write succeeds almost every time, however, 
>> after a reset command from u-boot, it usually fails. And with that 
>> increased timeout,when it fails I see:
>>
>> Check if pads/pull-ups of bus are properly configured
>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
>>
>> message 5 times during the failing write.
>>
>> How we end up there, is a mystery to me.
> 
> Yes...
> 
> Ok, on page 2671 is described when this ARDY event is triggered, so
> if we wait for it, we must first check, if the prerequisite is met...
> 
> Hmm.. the ARDY bit is also for interrupt mode described, see page 2778
> Figure 18-31 ... so I think it is correct to check it ... but
> I do not see, why we should wait for it in a loop and print
> an error if bit does not come up
> 
> But I have no time to dig into this ...
> 

Looks like slave device is misbehaving after a reset command. We changed 
the write to not reset the slave, but instead to disable the LED engine 
and it seems there are no more timeouts/errors. However, I guess it 
still makes sense some more complicated logic to be implemented there 
(like, if we write only one byte, do not wait for ARDY), as I doubt 
lp5523 is the only device that misbehaves on reset.

Ivo

U-Boot i2c bus num 1 is broken on Nokia N900

[Heiko Schocher]

Hello Ivaylo,

Am 31.10.2020 um 12:47 schrieb Ivaylo Dimitrov:
> 
> 
> On 30.10.20 ?. 9:24 ?., Heiko Schocher wrote:
>> Hello Ivaylo,
>>
>> Am 30.10.2020 um 08:00 schrieb Ivaylo Dimitrov:
>>> Hi,
>>>
>>> On 29.10.20 ?. 11:32 ?., Heiko Schocher wrote:
>>>> Hello Ivaylo,
>>>>
>>>> Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov:
>>>>> Hi,
>>>>>
>>>>> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote:
>>>>>> Hello Pali,
>>>>>>
>>>>>> sorry for late response ...
>>>>>>
>>>>>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r:
[snip]
>>>>>> Hannes may you can check if this is the case for you?
>>>>>>
>>>>>> why does nobody claimed that this message pops up in the last 5 years?
>>>>>>
>>>
>>> I can confirm I see it on the 2 devices I tested here.
>>>
>>> What is worse, is that writing on bus 1 does not fail every time. I increased I2C_TIMEOUT to 
>>> 100000 (the value from the TRM) and it seems now after power-cycle, write succeeds almost every 
>>> time, however, after a reset command from u-boot, it usually fails. And with that increased 
>>> timeout,when it fails I see:
>>>
>>> Check if pads/pull-ups of bus are properly configured
>>> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
>>>
>>> message 5 times during the failing write.
>>>
>>> How we end up there, is a mystery to me.
>>
>> Yes...
>>
>> Ok, on page 2671 is described when this ARDY event is triggered, so
>> if we wait for it, we must first check, if the prerequisite is met...
>>
>> Hmm.. the ARDY bit is also for interrupt mode described, see page 2778
>> Figure 18-31 ... so I think it is correct to check it ... but
>> I do not see, why we should wait for it in a loop and print
>> an error if bit does not come up
>>
>> But I have no time to dig into this ...
>>
> 
> Looks like slave device is misbehaving after a reset command. We changed the write to not reset the 
> slave, but instead to disable the LED engine and it seems there are no more timeouts/errors. 
> However, I guess it still makes sense some more complicated logic to be implemented there (like, if 
> we write only one byte, do not wait for ARDY), as I doubt lp5523 is the only device that misbehaves 
> on reset.

Uff... Ok, I cannot do/help here, as lack of time (and may hardware).

Hmm... may you try unblocking sequence instead?

Do you have time to look here deeper?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

U-Boot is broken on real N900 HW

[Pali Rohár]

On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > Hi,
> > > > >
> > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > >> problem.
> > > > > >
> > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > >
> > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > debug this issue.
> > > > > >
> > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > N900 device it generates repeating messages:
> > > > > >
> > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > >   Timed out in wait_for_event: status=0000
> > > > > >
> > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > problem is with OMAP I2C.
> > > > > >
> > > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > > prior was printed, not after.
> > > > > >
> > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > look at this reboot loop problem?
> > > > > >
> > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > work?
> > > > > >
> > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > U-Boot on real N900 hardware.
> > > > >
> > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > >
> > > > ...
> > > >
> > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > >
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > I2C:   ready
> > > > > DRAM:  256 MiB
> > > > > NAND:  0 Bytes
> > > >
> > > > Looks like that something with NAND is broken.
> > > >
> > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > In:    vga
> > > > > Out:   vga
> > > > > Err:   vga
> > > > > Timed out in wait_for_event: status=0100
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > Timed out in wait_for_event: status=0000
> > > > > Check if pads/pull-ups of bus are properly configured
> > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > i2c_write: timed out writig last byte!
> > > >
> > > > These i2c errors are caused by
> > > >
> > > >       /* reset lp5523 led */
> > > >       i2c_set_bus_num(1);
> > > >       state = 0xff;
> > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > >       i2c_set_bus_num(0);
> > > >
> > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > Because this code is working fine on older U-Boot version.
> > >
> > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > January 2015 it prints above error messages.
> > >
> > > On on internet forums I see these error messages also from other OMAP3
> > > board, e.g. beagle board.
> > >
> > > Has somebody some working OMAP3 board? And can test if it works with
> > > recent version of U-Boot? I guess that above i2c problem would happen
> > > also on other OMAP3 boards.
> > 
> > There was a conversion a while ago to dm_i2c, and I converted my board
> > to support using the device tree during the SPL phase, and whenever I
> > am aware any driver has driver model (DM) support, I try to convert my
> > board.
> > 
> > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> 
> Ok, so it either OMAP3430 specific problem or N900 board specific
> problem. N900 does not use driver model.
> 
> Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> it returned error.
> 
> If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> and basically U-Boot stopped responding.
> 
> So by above observation it looks like I2C bus num 1 does not work, but
> I2C bus num 0 works fine.
> 
> Do I need to call i2c_probe(...) before calling i2c_write(...)?
> 
> And is something special needed for initializing omap i2c bus num 1?
> Because from my above observation it looks like that something is
> missing for bus 1 which in older u-boot version was not needed.

I did one mistake here. i2c_probe() returns non-zero value for error.
In qemu it returns non-zero and on real HW it returns zero.

So i2c_probe() passes on real HW and then following i2c_write() cause
above "Check if pads/pull-ups of bus are properly configured" error
message. In qemu it looks like i2c writes are just discarded (maybe qemu
does not emulate this i2c device).

> > U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> > Trying to boot from MMC1
> > spl_load_image_fat_os: error reading image args, err - -2
> > 
> > 
> > U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> > 
> > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > DRAM:  256 MiB
> > NAND:  512 MiB
> > MMC:   OMAP SD/MMC: 0
> > Loading Environment from NAND... OK
> > OMAP die ID: 619e00029ff800000168300f1502501f
> > Net:   eth0: ethernet at 08000000
> > Hit any key to stop autoboot:  2
> > 
> > >
> > > > Was something changed to OMAP i2c bus code in U-Boot?
> > > >
> > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > >
> > > >
> > > > And then U-Boot freeze, right?
> > > >
> > > > Any idea how to debug this issue?
> > > >
> > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > reboot.
> > >
> > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > Was there some significat change to OMAP3 or omap hs mmc?
> > 
> > I booted by board from MMC as shown above.  I also use the pinctrl
> > features from the device tree to mux the pins in U-Boot (not SPL), so
> > my SPL only does manual muxing the essential components it needs
> > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > the pinmux because of message regarding pads/pull-ups.
> > 
> > adam
> 
> I debugged this problem more. I disabled all preboot commands to get
> clean U-Boot setup. And it worked.
> 
> After I called any "mmc" command (e.g. "mmc info") I got that instant
> board reboot. Preboot commands for n900 try to read some files from mmc,
> so this is reason why it get into reboot loop.
> 
> Is there any reason why "mmc info" command can cause "data abort" and
> instant reboot of board?
> 
> And do you know what is needed for proper initialization of omap mmc
> controller for omap3 board? Because it looks like something fundamental
> is missing.
> 
> Currently there are just calls for "omap_mmc_init()" functions and
> "twl4030_power_mmc_init()" functions. See:
> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

U-Boot is broken on real N900 HW

[Pali Rohár]

On Saturday 25 April 2020 14:07:31 Pali Roh?r wrote:
> On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > >
> > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > > >> problem.
> > > > > > >
> > > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > > >
> > > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > > debug this issue.
> > > > > > >
> > > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > > N900 device it generates repeating messages:
> > > > > > >
> > > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > > >   Timed out in wait_for_event: status=0000
> > > > > > >
> > > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > > problem is with OMAP I2C.
> > > > > > >
> > > > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > > > prior was printed, not after.
> > > > > > >
> > > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > > look at this reboot loop problem?
> > > > > > >
> > > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > > work?
> > > > > > >
> > > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > > U-Boot on real N900 hardware.
> > > > > >
> > > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > > >
> > > > > ...
> > > > >
> > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > >
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > I2C:   ready
> > > > > > DRAM:  256 MiB
> > > > > > NAND:  0 Bytes
> > > > >
> > > > > Looks like that something with NAND is broken.
> > > > >
> > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > In:    vga
> > > > > > Out:   vga
> > > > > > Err:   vga
> > > > > > Timed out in wait_for_event: status=0100
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > Timed out in wait_for_event: status=0000
> > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > i2c_write: timed out writig last byte!
> > > > >
> > > > > These i2c errors are caused by
> > > > >
> > > > >       /* reset lp5523 led */
> > > > >       i2c_set_bus_num(1);
> > > > >       state = 0xff;
> > > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > > >       i2c_set_bus_num(0);
> > > > >
> > > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > > Because this code is working fine on older U-Boot version.
> > > >
> > > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > > January 2015 it prints above error messages.
> > > >
> > > > On on internet forums I see these error messages also from other OMAP3
> > > > board, e.g. beagle board.
> > > >
> > > > Has somebody some working OMAP3 board? And can test if it works with
> > > > recent version of U-Boot? I guess that above i2c problem would happen
> > > > also on other OMAP3 boards.
> > > 
> > > There was a conversion a while ago to dm_i2c, and I converted my board
> > > to support using the device tree during the SPL phase, and whenever I
> > > am aware any driver has driver model (DM) support, I try to convert my
> > > board.
> > > 
> > > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> > 
> > Ok, so it either OMAP3430 specific problem or N900 board specific
> > problem. N900 does not use driver model.
> > 
> > Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> > it returned error.
> > 
> > If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> > and basically U-Boot stopped responding.
> > 
> > So by above observation it looks like I2C bus num 1 does not work, but
> > I2C bus num 0 works fine.
> > 
> > Do I need to call i2c_probe(...) before calling i2c_write(...)?
> > 
> > And is something special needed for initializing omap i2c bus num 1?
> > Because from my above observation it looks like that something is
> > missing for bus 1 which in older u-boot version was not needed.
> 
> I did one mistake here. i2c_probe() returns non-zero value for error.
> In qemu it returns non-zero and on real HW it returns zero.
> 
> So i2c_probe() passes on real HW and then following i2c_write() cause
> above "Check if pads/pull-ups of bus are properly configured" error
> message. In qemu it looks like i2c writes are just discarded (maybe qemu
> does not emulate this i2c device).

I see that in past somebody had same problem on omap3 beagle board:
https://lists.denx.de/pipermail/u-boot/2013-November/167969.html

I tried to add code from above email

  struct control_prog_io *prog_io_base;
  prog_io_base = (struct control_prog_io *)OMAP34XX_CTRL_BASE;
  /* Enable i2c2 pullup resisters */
  writel(~(PRG_I2C2_PULLUPRESX | PRG_I2C1_PULLUPRESX), &prog_io_base->io1);

but did not helped.

> > > U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> > > Trying to boot from MMC1
> > > spl_load_image_fat_os: error reading image args, err - -2
> > > 
> > > 
> > > U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> > > 
> > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > > DRAM:  256 MiB
> > > NAND:  512 MiB
> > > MMC:   OMAP SD/MMC: 0
> > > Loading Environment from NAND... OK
> > > OMAP die ID: 619e00029ff800000168300f1502501f
> > > Net:   eth0: ethernet at 08000000
> > > Hit any key to stop autoboot:  2
> > > 
> > > >
> > > > > Was something changed to OMAP i2c bus code in U-Boot?
> > > > >
> > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > >
> > > > >
> > > > > And then U-Boot freeze, right?
> > > > >
> > > > > Any idea how to debug this issue?
> > > > >
> > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > reboot.
> > > >
> > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > Was there some significat change to OMAP3 or omap hs mmc?
> > > 
> > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > my SPL only does manual muxing the essential components it needs
> > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > the pinmux because of message regarding pads/pull-ups.
> > > 
> > > adam
> > 
> > I debugged this problem more. I disabled all preboot commands to get
> > clean U-Boot setup. And it worked.
> > 
> > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > board reboot. Preboot commands for n900 try to read some files from mmc,
> > so this is reason why it get into reboot loop.
> > 
> > Is there any reason why "mmc info" command can cause "data abort" and
> > instant reboot of board?
> > 
> > And do you know what is needed for proper initialization of omap mmc
> > controller for omap3 board? Because it looks like something fundamental
> > is missing.
> > 
> > Currently there are just calls for "omap_mmc_init()" functions and
> > "twl4030_power_mmc_init()" functions. See:
> > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

U-Boot is broken on real N900 HW

[Pali Rohár]

On Saturday 25 April 2020 15:19:12 Pali Roh?r wrote:
> On Saturday 25 April 2020 14:07:31 Pali Roh?r wrote:
> > On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > >
> > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On 01/04/2020 00:42, Pali Roh?r wrote:
> > > > > > > > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > > > > > > >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > > > > > >> After these changes it is possible to run U-Boot in qemu emulator again.
> > > > > > > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > > > > > >> problem.
> > > > > > > >
> > > > > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > > > > > > >
> > > > > > > > I do not have serial console for Nokia N900 to debug this issue, but
> > > > > > > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > > > > > > > that there is no crash and even no error in qemu emulator so I cannot
> > > > > > > > debug this issue.
> > > > > > > >
> > > > > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > > > > > > > N900 device it generates repeating messages:
> > > > > > > >
> > > > > > > >   Check if pads/pull-ups of bus are properly configured
> > > > > > > >   Timed out in wait_for_event: status=0000
> > > > > > > >
> > > > > > > > When I commented that few lines all these messages disappeared. So
> > > > > > > > problem is with OMAP I2C.
> > > > > > > >
> > > > > > > > Second problem happen after misc_init_r() function finishes. U-Boot just
> > > > > > > > prints on N900 screen message "data abort" and reboots. As I do not have
> > > > > > > > serial console it is hard to debug. but I figured out that problem is in
> > > > > > > > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > > > > > > > debug info prior to mmc_set_ios() call and after it, and debug info
> > > > > > > > prior was printed, not after.
> > > > > > > >
> > > > > > > > I remember that somebody had serial jig for Nokia N900, could somebody
> > > > > > > > look at this reboot loop problem?
> > > > > > > >
> > > > > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > > > > > > > work?
> > > > > > > >
> > > > > > > > Maybe I will try to find some time to git bisect which change broke
> > > > > > > > U-Boot on real N900 hardware.
> > > > > > >
> > > > > > > Took latest u-boot master, applied patches and this is the result on
> > > > > > > serial (first part is NOLO booting, I think that can be ignored) [1].
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > > >
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > > I2C:   ready
> > > > > > > DRAM:  256 MiB
> > > > > > > NAND:  0 Bytes
> > > > > >
> > > > > > Looks like that something with NAND is broken.
> > > > > >
> > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > > > > > In:    vga
> > > > > > > Out:   vga
> > > > > > > Err:   vga
> > > > > > > Timed out in wait_for_event: status=0100
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > Timed out in wait_for_event: status=0000
> > > > > > > Check if pads/pull-ups of bus are properly configured
> > > > > > > i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> > > > > > > i2c_write: timed out writig last byte!
> > > > > >
> > > > > > These i2c errors are caused by
> > > > > >
> > > > > >       /* reset lp5523 led */
> > > > > >       i2c_set_bus_num(1);
> > > > > >       state = 0xff;
> > > > > >       i2c_write(0x32, 0x3d, 1, &state, 1);
> > > > > >       i2c_set_bus_num(0);
> > > > > >
> > > > > > Is there anything which needs to be done to initialize i2c bus 1?
> > > > > > Because this code is working fine on older U-Boot version.
> > > > >
> > > > > Above code worked fine for U-Boot 2013.04, but in git version from
> > > > > January 2015 it prints above error messages.
> > > > >
> > > > > On on internet forums I see these error messages also from other OMAP3
> > > > > board, e.g. beagle board.
> > > > >
> > > > > Has somebody some working OMAP3 board? And can test if it works with
> > > > > recent version of U-Boot? I guess that above i2c problem would happen
> > > > > also on other OMAP3 boards.
> > > > 
> > > > There was a conversion a while ago to dm_i2c, and I converted my board
> > > > to support using the device tree during the SPL phase, and whenever I
> > > > am aware any driver has driver model (DM) support, I try to convert my
> > > > board.
> > > > 
> > > > I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
> > > 
> > > Ok, so it either OMAP3430 specific problem or N900 board specific
> > > problem. N900 does not use driver model.
> > > 
> > > Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and
> > > it returned error.
> > > 
> > > If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors
> > > and basically U-Boot stopped responding.
> > > 
> > > So by above observation it looks like I2C bus num 1 does not work, but
> > > I2C bus num 0 works fine.
> > > 
> > > Do I need to call i2c_probe(...) before calling i2c_write(...)?
> > > 
> > > And is something special needed for initializing omap i2c bus num 1?
> > > Because from my above observation it looks like that something is
> > > missing for bus 1 which in older u-boot version was not needed.
> > 
> > I did one mistake here. i2c_probe() returns non-zero value for error.
> > In qemu it returns non-zero and on real HW it returns zero.
> > 
> > So i2c_probe() passes on real HW and then following i2c_write() cause
> > above "Check if pads/pull-ups of bus are properly configured" error
> > message. In qemu it looks like i2c writes are just discarded (maybe qemu
> > does not emulate this i2c device).
> 
> I see that in past somebody had same problem on omap3 beagle board:
> https://lists.denx.de/pipermail/u-boot/2013-November/167969.html
> 
> I tried to add code from above email
> 
>   struct control_prog_io *prog_io_base;
>   prog_io_base = (struct control_prog_io *)OMAP34XX_CTRL_BASE;
>   /* Enable i2c2 pullup resisters */
>   writel(~(PRG_I2C2_PULLUPRESX | PRG_I2C1_PULLUPRESX), &prog_io_base->io1);
> 
> but did not helped.

Now I figured out that function set_muxconf_regs() which setup board
pinmux configuration is not called.

Was something in U-Boot changed which caused that U-Boot does not call
board set_muxconf_regs() function anymore?

> > > > U-Boot SPL 2020.04-rc1-01140-ge1dff2d69e-dirty (Feb 15 2020 - 06:18:18 -0600)
> > > > Trying to boot from MMC1
> > > > spl_load_image_fat_os: error reading image args, err - -2
> > > > 
> > > > 
> > > > U-Boot 2020.04-rc3-00184-g860eba6a8f-dirty (Mar 26 2020 - 05:43:04 -0500)
> > > > 
> > > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> > > > Model: LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
> > > > Logic DM37x/OMAP35x reference board + LPDDR/NAND
> > > > DRAM:  256 MiB
> > > > NAND:  512 MiB
> > > > MMC:   OMAP SD/MMC: 0
> > > > Loading Environment from NAND... OK
> > > > OMAP die ID: 619e00029ff800000168300f1502501f
> > > > Net:   eth0: ethernet at 08000000
> > > > Hit any key to stop autoboot:  2
> > > > 
> > > > >
> > > > > > Was something changed to OMAP i2c bus code in U-Boot?
> > > > > >
> > > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > >
> > > > > >
> > > > > > And then U-Boot freeze, right?
> > > > > >
> > > > > > Any idea how to debug this issue?
> > > > > >
> > > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > > reboot.
> > > > >
> > > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > > Was there some significat change to OMAP3 or omap hs mmc?
> > > > 
> > > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > > my SPL only does manual muxing the essential components it needs
> > > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > > the pinmux because of message regarding pads/pull-ups.
> > > > 
> > > > adam
> > > 
> > > I debugged this problem more. I disabled all preboot commands to get
> > > clean U-Boot setup. And it worked.
> > > 
> > > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > > board reboot. Preboot commands for n900 try to read some files from mmc,
> > > so this is reason why it get into reboot loop.
> > > 
> > > Is there any reason why "mmc info" command can cause "data abort" and
> > > instant reboot of board?
> > > 
> > > And do you know what is needed for proper initialization of omap mmc
> > > controller for omap3 board? Because it looks like something fundamental
> > > is missing.
> > > 
> > > Currently there are just calls for "omap_mmc_init()" functions and
> > > "twl4030_power_mmc_init()" functions. See:
> > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

Bisected: mmc cause reboot loops on N900 (Was: Re: U-Boot is broken on real N900 HW)

[Pali Rohár]

Adding Jean to the loop. Could you please look at this problem? Your
commit (described below) is causing reboot loop on Nokia N900 hardware.

On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
...
> > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > >
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > I2C:   ready
> > > > > DRAM:  256 MiB
> > > > > NAND:  0 Bytes
...
> > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
...
> > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > >
> > > >
> > > > And then U-Boot freeze, right?
> > > >
> > > > Any idea how to debug this issue?
> > > >
> > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > reboot.
> > >
> > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > Was there some significat change to OMAP3 or omap hs mmc?
> > 
> > I booted by board from MMC as shown above.  I also use the pinctrl
> > features from the device tree to mux the pins in U-Boot (not SPL), so
> > my SPL only does manual muxing the essential components it needs
> > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > the pinmux because of message regarding pads/pull-ups.
> > 
> > adam
> 
> I debugged this problem more. I disabled all preboot commands to get
> clean U-Boot setup. And it worked.
> 
> After I called any "mmc" command (e.g. "mmc info") I got that instant
> board reboot. Preboot commands for n900 try to read some files from mmc,
> so this is reason why it get into reboot loop.
> 
> Is there any reason why "mmc info" command can cause "data abort" and
> instant reboot of board?
> 
> And do you know what is needed for proper initialization of omap mmc
> controller for omap3 board? Because it looks like something fundamental
> is missing.
> 
> Currently there are just calls for "omap_mmc_init()" functions and
> "twl4030_power_mmc_init()" functions. See:
> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c

Now I tried git bisect and here is problematic commit which caused whole
reboot loop:

04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
Date:   Thu Sep 21 16:30:08 2017 +0200

    mmc: disable UHS modes if Vcc cannot be switched on and off
    
    If a power cycle cannot be done on Vcc, it is safer not to try the UHS
    modes because we wouldn't be able to recover from an error occurring
    during the UHS initialization.
    
    Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

:040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
:040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include

It changes only core mmc code, nothing platform / board specific.
U-Boot compiled from commit before above has fully working eMMC access
on real Nokia N900. I can read files on FAT eMMC partition without any
problem.

I'm not sure what is happening here, but it looks like that omap hs mmc
driver used on Nokia N900 is maybe not correctly hooked for UHS support.

The most suspicious it that this problem cannot be reproduced in qemu
n900 emulator. It happens only on real N900 hw.

Bisected: mmc cause reboot loops on N900 (Was: Re: U-Boot is broken on real N900 HW)

[Pali Rohár]

On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> Adding Jean to the loop. Could you please look at this problem? Your
> commit (described below) is causing reboot loop on Nokia N900 hardware.
> 
> On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > >
> > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> ...
> > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > >
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > I2C:   ready
> > > > > > DRAM:  256 MiB
> > > > > > NAND:  0 Bytes
> ...
> > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> ...
> > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > >
> > > > >
> > > > > And then U-Boot freeze, right?
> > > > >
> > > > > Any idea how to debug this issue?
> > > > >
> > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > reboot.
> > > >
> > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > Was there some significat change to OMAP3 or omap hs mmc?
> > > 
> > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > my SPL only does manual muxing the essential components it needs
> > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > the pinmux because of message regarding pads/pull-ups.
> > > 
> > > adam
> > 
> > I debugged this problem more. I disabled all preboot commands to get
> > clean U-Boot setup. And it worked.
> > 
> > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > board reboot. Preboot commands for n900 try to read some files from mmc,
> > so this is reason why it get into reboot loop.
> > 
> > Is there any reason why "mmc info" command can cause "data abort" and
> > instant reboot of board?
> > 
> > And do you know what is needed for proper initialization of omap mmc
> > controller for omap3 board? Because it looks like something fundamental
> > is missing.
> > 
> > Currently there are just calls for "omap_mmc_init()" functions and
> > "twl4030_power_mmc_init()" functions. See:
> > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c
> 
> Now I tried git bisect and here is problematic commit which caused whole
> reboot loop:
> 
> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> Date:   Thu Sep 21 16:30:08 2017 +0200
> 
>     mmc: disable UHS modes if Vcc cannot be switched on and off
>     
>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
>     modes because we wouldn't be able to recover from an error occurring
>     during the UHS initialization.
>     
>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> 
> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> 
> It changes only core mmc code, nothing platform / board specific.
> U-Boot compiled from commit before above has fully working eMMC access
> on real Nokia N900. I can read files on FAT eMMC partition without any
> problem.
> 
> I'm not sure what is happening here, but it looks like that omap hs mmc
> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> 
> The most suspicious it that this problem cannot be reproduced in qemu
> n900 emulator. It happens only on real N900 hw.

I took main change from above commit, reverted it on master and U-Boot
stopped crashing! No reboot loop anymore. Here is change which fixes
reboot loop on Nokia N900:

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 523c055967..d07c7745da 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
 		      MMC_QUIRK_RETRY_APP_CMD;
 #endif
 
-	err = mmc_power_cycle(mmc);
-	if (err) {
-		/*
-		 * if power cycling is not supported, we should not try
-		 * to use the UHS modes, because we wouldn't be able to
-		 * recover from an error during the UHS initialization.
-		 */
-		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
-		uhs_en = false;
-		mmc->host_caps &= ~UHS_CAPS;
-		err = mmc_power_on(mmc);
-	}
+	err = mmc_power_on(mmc);
 	if (err)
 		return err;
 

Jean, do you have any idea what is happening in above code? It looks
like something is broken in power cycle / power on sequence if it cause
"data abort" and reboot of board.


But even with above my change eMMC on N900 cannot be initialized...
I'm running second git bisect with applying above change on every
commit. It is in progress now.

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Pali Rohár]

Adding also Faiz to loop...

On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> > Adding Jean to the loop. Could you please look at this problem? Your
> > commit (described below) is causing reboot loop on Nokia N900 hardware.
> > 
> > On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > >
> > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > ...
> > > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > > >
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > > I2C:   ready
> > > > > > > DRAM:  256 MiB
> > > > > > > NAND:  0 Bytes
> > ...
> > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > ...
> > > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > >
> > > > > >
> > > > > > And then U-Boot freeze, right?
> > > > > >
> > > > > > Any idea how to debug this issue?
> > > > > >
> > > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > > reboot.
> > > > >
> > > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > > Was there some significat change to OMAP3 or omap hs mmc?
> > > > 
> > > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > > my SPL only does manual muxing the essential components it needs
> > > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > > the pinmux because of message regarding pads/pull-ups.
> > > > 
> > > > adam
> > > 
> > > I debugged this problem more. I disabled all preboot commands to get
> > > clean U-Boot setup. And it worked.
> > > 
> > > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > > board reboot. Preboot commands for n900 try to read some files from mmc,
> > > so this is reason why it get into reboot loop.
> > > 
> > > Is there any reason why "mmc info" command can cause "data abort" and
> > > instant reboot of board?
> > > 
> > > And do you know what is needed for proper initialization of omap mmc
> > > controller for omap3 board? Because it looks like something fundamental
> > > is missing.
> > > 
> > > Currently there are just calls for "omap_mmc_init()" functions and
> > > "twl4030_power_mmc_init()" functions. See:
> > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c
> > 
> > Now I tried git bisect and here is problematic commit which caused whole
> > reboot loop:
> > 
> > 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> > commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> > Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > Date:   Thu Sep 21 16:30:08 2017 +0200
> > 
> >     mmc: disable UHS modes if Vcc cannot be switched on and off
> >     
> >     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> >     modes because we wouldn't be able to recover from an error occurring
> >     during the UHS initialization.
> >     
> >     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > 
> > :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> > :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> > 
> > It changes only core mmc code, nothing platform / board specific.
> > U-Boot compiled from commit before above has fully working eMMC access
> > on real Nokia N900. I can read files on FAT eMMC partition without any
> > problem.
> > 
> > I'm not sure what is happening here, but it looks like that omap hs mmc
> > driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> > 
> > The most suspicious it that this problem cannot be reproduced in qemu
> > n900 emulator. It happens only on real N900 hw.
> 
> I took main change from above commit, reverted it on master and U-Boot
> stopped crashing! No reboot loop anymore. Here is change which fixes
> reboot loop on Nokia N900:
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 523c055967..d07c7745da 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
>  		      MMC_QUIRK_RETRY_APP_CMD;
>  #endif
>  
> -	err = mmc_power_cycle(mmc);
> -	if (err) {
> -		/*
> -		 * if power cycling is not supported, we should not try
> -		 * to use the UHS modes, because we wouldn't be able to
> -		 * recover from an error during the UHS initialization.
> -		 */
> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> -		uhs_en = false;
> -		mmc->host_caps &= ~UHS_CAPS;
> -		err = mmc_power_on(mmc);
> -	}
> +	err = mmc_power_on(mmc);
>  	if (err)
>  		return err;
>  
> 
> Jean, do you have any idea what is happening in above code? It looks
> like something is broken in power cycle / power on sequence if it cause
> "data abort" and reboot of board.
> 
> 
> But even with above my change eMMC on N900 cannot be initialized...
> I'm running second git bisect with applying above change on every
> commit. It is in progress now.

And second bisect finished. Result is:

d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
commit d2c05f50e12f87128597a28146de7092aaa847c3
Author: Faiz Abbas <faiz_abbas@ti.com>
Date:   Fri Apr 5 14:18:46 2019 +0530

    mmc: omap_hsmmc: Set 3.3V for IO voltage
    
    Pbias voltage should match the IO voltage set for the SD card. With the
    latest pbias change to 3.3V, update the capabilities and IO voltages
    settings to 3.3V.
    
    Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>

:040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers

I revered above commit on top of master and eMMC on Nokia N900 finally
started working again!

Faiz, what is the reason for above commit? It basically changes in omap
hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
incompatible with Nokia N900. Are there any problems with 3.0V on some
omap3 boards? If not I would vote for revering that commit. Or at least
making IO voltage configurable.

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Faiz Abbas]

Pali,


On 26/04/20 3:59 am, Pali Roh?r wrote:
> Adding also Faiz to loop...
> 
> On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
>> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
>>> Adding Jean to the loop. Could you please look at this problem? Your
>>> commit (described below) is causing reboot loop on Nokia N900 hardware.
>>>
>>> On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
>>>> On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
>>>>> On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
>>>>>>
>>>>>> On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
>>>>>>> On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
>>> ...
>>>>>>>> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
>>>>>>>>
>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>> Nokia RX-51 + LPDDR/OneNAND
>>>>>>>> I2C:   ready
>>>>>>>> DRAM:  256 MiB
>>>>>>>> NAND:  0 Bytes
>>> ...
>>>>>>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>> ...
>>>>>>>> OMAP die ID: 031400240000000004036ac10b01100f
>>>>>>>> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>>>>>>>>
>>>>>>>
>>>>>>> And then U-Boot freeze, right?
>>>>>>>
>>>>>>> Any idea how to debug this issue?
>>>>>>>
>>>>>>> On my N900 I'm getting "data abort" error on display and then instant
>>>>>>> reboot.
>>>>>>
>>>>>> It looks like that omap hs mmc code cause that freeze/reboot on real HW.
>>>>>> Was there some significat change to OMAP3 or omap hs mmc?
>>>>>
>>>>> I booted by board from MMC as shown above.  I also use the pinctrl
>>>>> features from the device tree to mux the pins in U-Boot (not SPL), so
>>>>> my SPL only does manual muxing the essential components it needs
>>>>> during the SPL phase, and lets U-Boot do the rest.   I only  mention
>>>>> the pinmux because of message regarding pads/pull-ups.
>>>>>
>>>>> adam
>>>>
>>>> I debugged this problem more. I disabled all preboot commands to get
>>>> clean U-Boot setup. And it worked.
>>>>
>>>> After I called any "mmc" command (e.g. "mmc info") I got that instant
>>>> board reboot. Preboot commands for n900 try to read some files from mmc,
>>>> so this is reason why it get into reboot loop.
>>>>
>>>> Is there any reason why "mmc info" command can cause "data abort" and
>>>> instant reboot of board?
>>>>
>>>> And do you know what is needed for proper initialization of omap mmc
>>>> controller for omap3 board? Because it looks like something fundamental
>>>> is missing.
>>>>
>>>> Currently there are just calls for "omap_mmc_init()" functions and
>>>> "twl4030_power_mmc_init()" functions. See:
>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c
>>>
>>> Now I tried git bisect and here is problematic commit which caused whole
>>> reboot loop:
>>>
>>> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
>>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
>>> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>> Date:   Thu Sep 21 16:30:08 2017 +0200
>>>
>>>     mmc: disable UHS modes if Vcc cannot be switched on and off
>>>     
>>>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
>>>     modes because we wouldn't be able to recover from an error occurring
>>>     during the UHS initialization.
>>>     
>>>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>>
>>> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
>>> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
>>>
>>> It changes only core mmc code, nothing platform / board specific.
>>> U-Boot compiled from commit before above has fully working eMMC access
>>> on real Nokia N900. I can read files on FAT eMMC partition without any
>>> problem.
>>>
>>> I'm not sure what is happening here, but it looks like that omap hs mmc
>>> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
>>>
>>> The most suspicious it that this problem cannot be reproduced in qemu
>>> n900 emulator. It happens only on real N900 hw.
>>
>> I took main change from above commit, reverted it on master and U-Boot
>> stopped crashing! No reboot loop anymore. Here is change which fixes
>> reboot loop on Nokia N900:
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 523c055967..d07c7745da 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
>>  		      MMC_QUIRK_RETRY_APP_CMD;
>>  #endif
>>  
>> -	err = mmc_power_cycle(mmc);
>> -	if (err) {
>> -		/*
>> -		 * if power cycling is not supported, we should not try
>> -		 * to use the UHS modes, because we wouldn't be able to
>> -		 * recover from an error during the UHS initialization.
>> -		 */
>> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
>> -		uhs_en = false;
>> -		mmc->host_caps &= ~UHS_CAPS;
>> -		err = mmc_power_on(mmc);
>> -	}
>> +	err = mmc_power_on(mmc);
>>  	if (err)
>>  		return err;
>>  
>>
>> Jean, do you have any idea what is happening in above code? It looks
>> like something is broken in power cycle / power on sequence if it cause
>> "data abort" and reboot of board.
>>
>>
>> But even with above my change eMMC on N900 cannot be initialized...
>> I'm running second git bisect with applying above change on every
>> commit. It is in progress now.
> 
> And second bisect finished. Result is:
> 
> d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
> commit d2c05f50e12f87128597a28146de7092aaa847c3
> Author: Faiz Abbas <faiz_abbas@ti.com>
> Date:   Fri Apr 5 14:18:46 2019 +0530
> 
>     mmc: omap_hsmmc: Set 3.3V for IO voltage
>     
>     Pbias voltage should match the IO voltage set for the SD card. With the
>     latest pbias change to 3.3V, update the capabilities and IO voltages
>     settings to 3.3V.
>     
>     Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> 
> :040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers
> 
> I revered above commit on top of master and eMMC on Nokia N900 finally
> started working again!
> 
> Faiz, what is the reason for above commit? It basically changes in omap
> hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
> incompatible with Nokia N900. Are there any problems with 3.0V on some
> omap3 boards? If not I would vote for revering that commit. Or at least
> making IO voltage configurable.
> 

For the power_cycle patch, it looks like there is a null pointer dereference
that might be causing the reboot loops (probably because your platform doesn't
have DM_MMC enabled) Can you add a few more prints to see where the data abort
comes from exactly?

For the second patch IO voltage patch, what exactly do you see without reverting it?
Are you able to reach prompt but mmc commands fail? Its possible that your platform
requires a pbias of 3.0V to work.

PS: In the next version of these patches, please follow file prefixes for each commit
instead of one blanket NOKIA RX-511: prefix.

Thanks,
Faiz

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Pali Rohár]

On Thursday 07 May 2020 19:10:14 Faiz Abbas wrote:
> On 26/04/20 3:59 am, Pali Roh?r wrote:
> > On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> >> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> >>> Now I tried git bisect and here is problematic commit which caused whole
> >>> reboot loop:
> >>>
> >>> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> >>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> >>> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> >>> Date:   Thu Sep 21 16:30:08 2017 +0200
> >>>
> >>>     mmc: disable UHS modes if Vcc cannot be switched on and off
> >>>     
> >>>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> >>>     modes because we wouldn't be able to recover from an error occurring
> >>>     during the UHS initialization.
> >>>     
> >>>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> >>>
> >>> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> >>> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> >>>
> >>> It changes only core mmc code, nothing platform / board specific.
> >>> U-Boot compiled from commit before above has fully working eMMC access
> >>> on real Nokia N900. I can read files on FAT eMMC partition without any
> >>> problem.
> >>>
> >>> I'm not sure what is happening here, but it looks like that omap hs mmc
> >>> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> >>>
> >>> The most suspicious it that this problem cannot be reproduced in qemu
> >>> n900 emulator. It happens only on real N900 hw.
> >>
> >> I took main change from above commit, reverted it on master and U-Boot
> >> stopped crashing! No reboot loop anymore. Here is change which fixes
> >> reboot loop on Nokia N900:
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index 523c055967..d07c7745da 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
> >>  		      MMC_QUIRK_RETRY_APP_CMD;
> >>  #endif
> >>  
> >> -	err = mmc_power_cycle(mmc);
> >> -	if (err) {
> >> -		/*
> >> -		 * if power cycling is not supported, we should not try
> >> -		 * to use the UHS modes, because we wouldn't be able to
> >> -		 * recover from an error during the UHS initialization.
> >> -		 */
> >> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> >> -		uhs_en = false;
> >> -		mmc->host_caps &= ~UHS_CAPS;
> >> -		err = mmc_power_on(mmc);
> >> -	}
> >> +	err = mmc_power_on(mmc);
> >>  	if (err)
> >>  		return err;
> >>  
> >>
> >> Jean, do you have any idea what is happening in above code? It looks
> >> like something is broken in power cycle / power on sequence if it cause
> >> "data abort" and reboot of board.
> >>
> >>
> >> But even with above my change eMMC on N900 cannot be initialized...
> >> I'm running second git bisect with applying above change on every
> >> commit. It is in progress now.
> > 
> > And second bisect finished. Result is:
> > 
> > d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
> > commit d2c05f50e12f87128597a28146de7092aaa847c3
> > Author: Faiz Abbas <faiz_abbas@ti.com>
> > Date:   Fri Apr 5 14:18:46 2019 +0530
> > 
> >     mmc: omap_hsmmc: Set 3.3V for IO voltage
> >     
> >     Pbias voltage should match the IO voltage set for the SD card. With the
> >     latest pbias change to 3.3V, update the capabilities and IO voltages
> >     settings to 3.3V.
> >     
> >     Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > 
> > :040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers
> > 
> > I revered above commit on top of master and eMMC on Nokia N900 finally
> > started working again!
> > 
> > Faiz, what is the reason for above commit? It basically changes in omap
> > hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
> > incompatible with Nokia N900. Are there any problems with 3.0V on some
> > omap3 boards? If not I would vote for revering that commit. Or at least
> > making IO voltage configurable.
> > 
> 
> For the power_cycle patch, it looks like there is a null pointer dereference
> that might be causing the reboot loops (probably because your platform doesn't
> have DM_MMC enabled) Can you add a few more prints to see where the data abort
> comes from exactly?

Hello Faiz!

Sorry, but this is problematic. Because of reboot loops I cannot read
what exactly is put on the display and reboot cause clearing display.

Month ago I was able to detect that problem is somewhere in function
mmc_set_ios() from mmc.c file. I put long debug line prior and also
after mmc_set_ios() call. And it was printed only prior. Not after.
So I think NULL pointer dereference is in mmc_set_ios() function.

> For the second patch IO voltage patch, what exactly do you see without reverting it?
> Are you able to reach prompt but mmc commands fail?

Yes, after reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 there is
no reboot loop anymore. Just mmc commands fail and eMMC is not detected
at all.

> Its possible that your platform requires a pbias of 3.0V to work.
> 
> PS: In the next version of these patches, please follow file prefixes for each commit
> instead of one blanket NOKIA RX-511: prefix.

File prefix is nokia rx-51. So which prefix would you want to see? But I
think I would not send new version of these patches as Tom already wrote
that is fine with them and I guess he would take them (or maybe already
merged?).

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Pali Rohár]

On Thursday 07 May 2020 17:19:38 Pali Roh?r wrote:
> On Thursday 07 May 2020 19:10:14 Faiz Abbas wrote:
> > On 26/04/20 3:59 am, Pali Roh?r wrote:
> > > On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> > >> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> > >>> Now I tried git bisect and here is problematic commit which caused whole
> > >>> reboot loop:
> > >>>
> > >>> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> > >>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> > >>> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > >>> Date:   Thu Sep 21 16:30:08 2017 +0200
> > >>>
> > >>>     mmc: disable UHS modes if Vcc cannot be switched on and off
> > >>>     
> > >>>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> > >>>     modes because we wouldn't be able to recover from an error occurring
> > >>>     during the UHS initialization.
> > >>>     
> > >>>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > >>>
> > >>> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> > >>> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> > >>>
> > >>> It changes only core mmc code, nothing platform / board specific.
> > >>> U-Boot compiled from commit before above has fully working eMMC access
> > >>> on real Nokia N900. I can read files on FAT eMMC partition without any
> > >>> problem.
> > >>>
> > >>> I'm not sure what is happening here, but it looks like that omap hs mmc
> > >>> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> > >>>
> > >>> The most suspicious it that this problem cannot be reproduced in qemu
> > >>> n900 emulator. It happens only on real N900 hw.
> > >>
> > >> I took main change from above commit, reverted it on master and U-Boot
> > >> stopped crashing! No reboot loop anymore. Here is change which fixes
> > >> reboot loop on Nokia N900:
> > >>
> > >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > >> index 523c055967..d07c7745da 100644
> > >> --- a/drivers/mmc/mmc.c
> > >> +++ b/drivers/mmc/mmc.c
> > >> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
> > >>  		      MMC_QUIRK_RETRY_APP_CMD;
> > >>  #endif
> > >>  
> > >> -	err = mmc_power_cycle(mmc);
> > >> -	if (err) {
> > >> -		/*
> > >> -		 * if power cycling is not supported, we should not try
> > >> -		 * to use the UHS modes, because we wouldn't be able to
> > >> -		 * recover from an error during the UHS initialization.
> > >> -		 */
> > >> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> > >> -		uhs_en = false;
> > >> -		mmc->host_caps &= ~UHS_CAPS;
> > >> -		err = mmc_power_on(mmc);
> > >> -	}
> > >> +	err = mmc_power_on(mmc);
> > >>  	if (err)
> > >>  		return err;
> > >>  
> > >>
> > >> Jean, do you have any idea what is happening in above code? It looks
> > >> like something is broken in power cycle / power on sequence if it cause
> > >> "data abort" and reboot of board.
> > >>
> > >>
> > >> But even with above my change eMMC on N900 cannot be initialized...
> > >> I'm running second git bisect with applying above change on every
> > >> commit. It is in progress now.
> > > 
> > > And second bisect finished. Result is:
> > > 
> > > d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
> > > commit d2c05f50e12f87128597a28146de7092aaa847c3
> > > Author: Faiz Abbas <faiz_abbas@ti.com>
> > > Date:   Fri Apr 5 14:18:46 2019 +0530
> > > 
> > >     mmc: omap_hsmmc: Set 3.3V for IO voltage
> > >     
> > >     Pbias voltage should match the IO voltage set for the SD card. With the
> > >     latest pbias change to 3.3V, update the capabilities and IO voltages
> > >     settings to 3.3V.
> > >     
> > >     Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > > 
> > > :040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers
> > > 
> > > I revered above commit on top of master and eMMC on Nokia N900 finally
> > > started working again!
> > > 
> > > Faiz, what is the reason for above commit? It basically changes in omap
> > > hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
> > > incompatible with Nokia N900. Are there any problems with 3.0V on some
> > > omap3 boards? If not I would vote for revering that commit. Or at least
> > > making IO voltage configurable.
> > > 
> > 
> > For the power_cycle patch, it looks like there is a null pointer dereference
> > that might be causing the reboot loops (probably because your platform doesn't
> > have DM_MMC enabled) Can you add a few more prints to see where the data abort
> > comes from exactly?
> 
> Hello Faiz!
> 
> Sorry, but this is problematic. Because of reboot loops I cannot read
> what exactly is put on the display and reboot cause clearing display.
> 
> Month ago I was able to detect that problem is somewhere in function
> mmc_set_ios() from mmc.c file. I put long debug line prior and also
> after mmc_set_ios() call. And it was printed only prior. Not after.
> So I think NULL pointer dereference is in mmc_set_ios() function.
> 
> > For the second patch IO voltage patch, what exactly do you see without reverting it?
> > Are you able to reach prompt but mmc commands fail?
> 
> Yes, after reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 there is
> no reboot loop anymore. Just mmc commands fail and eMMC is not detected
> at all.
> 
> > Its possible that your platform requires a pbias of 3.0V to work.

Hello Faiz!

Now I figured out what is the root cause of second 3.0V vs 3.3V problem.

In commit d2c05f50e12f87128597a28146de7092aaa847c3 you forgot to replace
one usage of 3.0V by 3.3V. Below is patch which changes also this last
one usage. Applying it has same effect on Nokia N900 as reverting
that problematic commit d2c05f50e12f87128597a28146de7092aaa847c3:

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 8636cd713a..dc26e54795 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -840,7 +840,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
 	omap_hsmmc_conf_bus_power(mmc, (reg_val & VS33_3V3SUP) ?
 			  MMC_SIGNAL_VOLTAGE_330 : MMC_SIGNAL_VOLTAGE_180);
 #else
-	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
+	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V3, &mmc_base->hctl);
 	writel(readl(&mmc_base->capa) | VS33_3V3SUP | VS18_1V8SUP,
 		&mmc_base->capa);
 #endif

So eMMC on real N900 is working fine either with 3.0V or 3.3V. But 3.3V
needs to be configured on all places.

First problem with reboot loop and crash in mmc_set_ios() still remains.
Reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 fixes it.

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Pali Rohár]

On Tuesday 26 May 2020 19:49:54 Pali Roh?r wrote:
> On Thursday 07 May 2020 17:19:38 Pali Roh?r wrote:
> > On Thursday 07 May 2020 19:10:14 Faiz Abbas wrote:
> > > On 26/04/20 3:59 am, Pali Roh?r wrote:
> > > > On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> > > >> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> > > >>> Now I tried git bisect and here is problematic commit which caused whole
> > > >>> reboot loop:
> > > >>>
> > > >>> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> > > >>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> > > >>> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > >>> Date:   Thu Sep 21 16:30:08 2017 +0200
> > > >>>
> > > >>>     mmc: disable UHS modes if Vcc cannot be switched on and off
> > > >>>     
> > > >>>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> > > >>>     modes because we wouldn't be able to recover from an error occurring
> > > >>>     during the UHS initialization.
> > > >>>     
> > > >>>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > >>>
> > > >>> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> > > >>> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> > > >>>
> > > >>> It changes only core mmc code, nothing platform / board specific.
> > > >>> U-Boot compiled from commit before above has fully working eMMC access
> > > >>> on real Nokia N900. I can read files on FAT eMMC partition without any
> > > >>> problem.
> > > >>>
> > > >>> I'm not sure what is happening here, but it looks like that omap hs mmc
> > > >>> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> > > >>>
> > > >>> The most suspicious it that this problem cannot be reproduced in qemu
> > > >>> n900 emulator. It happens only on real N900 hw.
> > > >>
> > > >> I took main change from above commit, reverted it on master and U-Boot
> > > >> stopped crashing! No reboot loop anymore. Here is change which fixes
> > > >> reboot loop on Nokia N900:
> > > >>
> > > >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > > >> index 523c055967..d07c7745da 100644
> > > >> --- a/drivers/mmc/mmc.c
> > > >> +++ b/drivers/mmc/mmc.c
> > > >> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
> > > >>  		      MMC_QUIRK_RETRY_APP_CMD;
> > > >>  #endif
> > > >>  
> > > >> -	err = mmc_power_cycle(mmc);
> > > >> -	if (err) {
> > > >> -		/*
> > > >> -		 * if power cycling is not supported, we should not try
> > > >> -		 * to use the UHS modes, because we wouldn't be able to
> > > >> -		 * recover from an error during the UHS initialization.
> > > >> -		 */
> > > >> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> > > >> -		uhs_en = false;
> > > >> -		mmc->host_caps &= ~UHS_CAPS;
> > > >> -		err = mmc_power_on(mmc);
> > > >> -	}
> > > >> +	err = mmc_power_on(mmc);
> > > >>  	if (err)
> > > >>  		return err;
> > > >>  
> > > >>
> > > >> Jean, do you have any idea what is happening in above code? It looks
> > > >> like something is broken in power cycle / power on sequence if it cause
> > > >> "data abort" and reboot of board.
> > > >>
> > > >>
> > > >> But even with above my change eMMC on N900 cannot be initialized...
> > > >> I'm running second git bisect with applying above change on every
> > > >> commit. It is in progress now.
> > > > 
> > > > And second bisect finished. Result is:
> > > > 
> > > > d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
> > > > commit d2c05f50e12f87128597a28146de7092aaa847c3
> > > > Author: Faiz Abbas <faiz_abbas@ti.com>
> > > > Date:   Fri Apr 5 14:18:46 2019 +0530
> > > > 
> > > >     mmc: omap_hsmmc: Set 3.3V for IO voltage
> > > >     
> > > >     Pbias voltage should match the IO voltage set for the SD card. With the
> > > >     latest pbias change to 3.3V, update the capabilities and IO voltages
> > > >     settings to 3.3V.
> > > >     
> > > >     Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > > > 
> > > > :040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers
> > > > 
> > > > I revered above commit on top of master and eMMC on Nokia N900 finally
> > > > started working again!
> > > > 
> > > > Faiz, what is the reason for above commit? It basically changes in omap
> > > > hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
> > > > incompatible with Nokia N900. Are there any problems with 3.0V on some
> > > > omap3 boards? If not I would vote for revering that commit. Or at least
> > > > making IO voltage configurable.
> > > > 
> > > 
> > > For the power_cycle patch, it looks like there is a null pointer dereference
> > > that might be causing the reboot loops (probably because your platform doesn't
> > > have DM_MMC enabled) Can you add a few more prints to see where the data abort
> > > comes from exactly?
> > 
> > Hello Faiz!
> > 
> > Sorry, but this is problematic. Because of reboot loops I cannot read
> > what exactly is put on the display and reboot cause clearing display.
> > 
> > Month ago I was able to detect that problem is somewhere in function
> > mmc_set_ios() from mmc.c file. I put long debug line prior and also
> > after mmc_set_ios() call. And it was printed only prior. Not after.
> > So I think NULL pointer dereference is in mmc_set_ios() function.
> > 
> > > For the second patch IO voltage patch, what exactly do you see without reverting it?
> > > Are you able to reach prompt but mmc commands fail?
> > 
> > Yes, after reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 there is
> > no reboot loop anymore. Just mmc commands fail and eMMC is not detected
> > at all.
> > 
> > > Its possible that your platform requires a pbias of 3.0V to work.
> 
> Hello Faiz!
> 
> Now I figured out what is the root cause of second 3.0V vs 3.3V problem.
> 
> In commit d2c05f50e12f87128597a28146de7092aaa847c3 you forgot to replace
> one usage of 3.0V by 3.3V. Below is patch which changes also this last
> one usage. Applying it has same effect on Nokia N900 as reverting
> that problematic commit d2c05f50e12f87128597a28146de7092aaa847c3:
> 
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index 8636cd713a..dc26e54795 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -840,7 +840,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
>  	omap_hsmmc_conf_bus_power(mmc, (reg_val & VS33_3V3SUP) ?
>  			  MMC_SIGNAL_VOLTAGE_330 : MMC_SIGNAL_VOLTAGE_180);
>  #else
> -	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
> +	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V3, &mmc_base->hctl);
>  	writel(readl(&mmc_base->capa) | VS33_3V3SUP | VS18_1V8SUP,
>  		&mmc_base->capa);
>  #endif
> 
> So eMMC on real N900 is working fine either with 3.0V or 3.3V. But 3.3V
> needs to be configured on all places.

Hello! Could you please take a look at this issue and my above fix?

> First problem with reboot loop and crash in mmc_set_ios() still remains.
> Reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 fixes it.

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Pali Rohár]

On Friday 12 June 2020 15:03:06 Pali Roh?r wrote:
> On Tuesday 26 May 2020 19:49:54 Pali Roh?r wrote:
> > On Thursday 07 May 2020 17:19:38 Pali Roh?r wrote:
> > > On Thursday 07 May 2020 19:10:14 Faiz Abbas wrote:
> > > > On 26/04/20 3:59 am, Pali Roh?r wrote:
> > > > > On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> > > > >> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> > > > >>> Now I tried git bisect and here is problematic commit which caused whole
> > > > >>> reboot loop:
> > > > >>>
> > > > >>> 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> > > > >>> commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> > > > >>> Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > > >>> Date:   Thu Sep 21 16:30:08 2017 +0200
> > > > >>>
> > > > >>>     mmc: disable UHS modes if Vcc cannot be switched on and off
> > > > >>>     
> > > > >>>     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> > > > >>>     modes because we wouldn't be able to recover from an error occurring
> > > > >>>     during the UHS initialization.
> > > > >>>     
> > > > >>>     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > > >>>
> > > > >>> :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> > > > >>> :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> > > > >>>
> > > > >>> It changes only core mmc code, nothing platform / board specific.
> > > > >>> U-Boot compiled from commit before above has fully working eMMC access
> > > > >>> on real Nokia N900. I can read files on FAT eMMC partition without any
> > > > >>> problem.
> > > > >>>
> > > > >>> I'm not sure what is happening here, but it looks like that omap hs mmc
> > > > >>> driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> > > > >>>
> > > > >>> The most suspicious it that this problem cannot be reproduced in qemu
> > > > >>> n900 emulator. It happens only on real N900 hw.
> > > > >>
> > > > >> I took main change from above commit, reverted it on master and U-Boot
> > > > >> stopped crashing! No reboot loop anymore. Here is change which fixes
> > > > >> reboot loop on Nokia N900:
> > > > >>
> > > > >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > > > >> index 523c055967..d07c7745da 100644
> > > > >> --- a/drivers/mmc/mmc.c
> > > > >> +++ b/drivers/mmc/mmc.c
> > > > >> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
> > > > >>  		      MMC_QUIRK_RETRY_APP_CMD;
> > > > >>  #endif
> > > > >>  
> > > > >> -	err = mmc_power_cycle(mmc);
> > > > >> -	if (err) {
> > > > >> -		/*
> > > > >> -		 * if power cycling is not supported, we should not try
> > > > >> -		 * to use the UHS modes, because we wouldn't be able to
> > > > >> -		 * recover from an error during the UHS initialization.
> > > > >> -		 */
> > > > >> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> > > > >> -		uhs_en = false;
> > > > >> -		mmc->host_caps &= ~UHS_CAPS;
> > > > >> -		err = mmc_power_on(mmc);
> > > > >> -	}
> > > > >> +	err = mmc_power_on(mmc);
> > > > >>  	if (err)
> > > > >>  		return err;
> > > > >>  
> > > > >>
> > > > >> Jean, do you have any idea what is happening in above code? It looks
> > > > >> like something is broken in power cycle / power on sequence if it cause
> > > > >> "data abort" and reboot of board.
> > > > >>
> > > > >>
> > > > >> But even with above my change eMMC on N900 cannot be initialized...
> > > > >> I'm running second git bisect with applying above change on every
> > > > >> commit. It is in progress now.
> > > > > 
> > > > > And second bisect finished. Result is:
> > > > > 
> > > > > d2c05f50e12f87128597a28146de7092aaa847c3 is the first bad commit
> > > > > commit d2c05f50e12f87128597a28146de7092aaa847c3
> > > > > Author: Faiz Abbas <faiz_abbas@ti.com>
> > > > > Date:   Fri Apr 5 14:18:46 2019 +0530
> > > > > 
> > > > >     mmc: omap_hsmmc: Set 3.3V for IO voltage
> > > > >     
> > > > >     Pbias voltage should match the IO voltage set for the SD card. With the
> > > > >     latest pbias change to 3.3V, update the capabilities and IO voltages
> > > > >     settings to 3.3V.
> > > > >     
> > > > >     Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > > > > 
> > > > > :040000 040000 819148217b64a6beaf8247464de6b4384d4581a4 e4fd9288ddb794f33596339813d5386f3bed8fd7 M      drivers
> > > > > 
> > > > > I revered above commit on top of master and eMMC on Nokia N900 finally
> > > > > started working again!
> > > > > 
> > > > > Faiz, what is the reason for above commit? It basically changes in omap
> > > > > hs mmc driver IO voltage from 3.0V to 3.3V. And seems this change is
> > > > > incompatible with Nokia N900. Are there any problems with 3.0V on some
> > > > > omap3 boards? If not I would vote for revering that commit. Or at least
> > > > > making IO voltage configurable.
> > > > > 
> > > > 
> > > > For the power_cycle patch, it looks like there is a null pointer dereference
> > > > that might be causing the reboot loops (probably because your platform doesn't
> > > > have DM_MMC enabled) Can you add a few more prints to see where the data abort
> > > > comes from exactly?
> > > 
> > > Hello Faiz!
> > > 
> > > Sorry, but this is problematic. Because of reboot loops I cannot read
> > > what exactly is put on the display and reboot cause clearing display.
> > > 
> > > Month ago I was able to detect that problem is somewhere in function
> > > mmc_set_ios() from mmc.c file. I put long debug line prior and also
> > > after mmc_set_ios() call. And it was printed only prior. Not after.
> > > So I think NULL pointer dereference is in mmc_set_ios() function.
> > > 
> > > > For the second patch IO voltage patch, what exactly do you see without reverting it?
> > > > Are you able to reach prompt but mmc commands fail?
> > > 
> > > Yes, after reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 there is
> > > no reboot loop anymore. Just mmc commands fail and eMMC is not detected
> > > at all.
> > > 
> > > > Its possible that your platform requires a pbias of 3.0V to work.
> > 
> > Hello Faiz!
> > 
> > Now I figured out what is the root cause of second 3.0V vs 3.3V problem.
> > 
> > In commit d2c05f50e12f87128597a28146de7092aaa847c3 you forgot to replace
> > one usage of 3.0V by 3.3V. Below is patch which changes also this last
> > one usage. Applying it has same effect on Nokia N900 as reverting
> > that problematic commit d2c05f50e12f87128597a28146de7092aaa847c3:
> > 
> > diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> > index 8636cd713a..dc26e54795 100644
> > --- a/drivers/mmc/omap_hsmmc.c
> > +++ b/drivers/mmc/omap_hsmmc.c
> > @@ -840,7 +840,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
> >  	omap_hsmmc_conf_bus_power(mmc, (reg_val & VS33_3V3SUP) ?
> >  			  MMC_SIGNAL_VOLTAGE_330 : MMC_SIGNAL_VOLTAGE_180);
> >  #else
> > -	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
> > +	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V3, &mmc_base->hctl);
> >  	writel(readl(&mmc_base->capa) | VS33_3V3SUP | VS18_1V8SUP,
> >  		&mmc_base->capa);
> >  #endif
> > 
> > So eMMC on real N900 is working fine either with 3.0V or 3.3V. But 3.3V
> > needs to be configured on all places.
> 
> Hello! Could you please take a look at this issue and my above fix?

Ping. Any comment for above issue or my fix?

> > First problem with reboot loop and crash in mmc_set_ios() still remains.
> > Reverting 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 fixes it.

Bisected: omap_hsmmc 3.3V IO voltage incompatible with N900 (Was: Re: Bisected: mmc cause reboot loops on N900)

[Faiz Abbas]

Hi Pali,

On 01/07/20 2:02 pm, Pali Roh?r wrote:
> On Friday 12 June 2020 15:03:06 Pali Roh?r wrote:
>> On Tuesday 26 May 2020 19:49:54 Pali Roh?r wrote:
>>> On Thursday 07 May 2020 17:19:38 Pali Roh?r wrote:
>>>> On Thursday 07 May 2020 19:10:14 Faiz Abbas wrote:
>>>>> On 26/04/20 3:59 am, Pali Roh?r wrote:
>>>>>> On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
>>>>>>> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
>>>>>>>> Now I tried git bisect and here is problematic commit which caused whole
>>>>>>>> reboot loop:
>>>>>>>>
...
>>>
>>> Hello Faiz!
>>>
>>> Now I figured out what is the root cause of second 3.0V vs 3.3V problem.
>>>
>>> In commit d2c05f50e12f87128597a28146de7092aaa847c3 you forgot to replace
>>> one usage of 3.0V by 3.3V. Below is patch which changes also this last
>>> one usage. Applying it has same effect on Nokia N900 as reverting
>>> that problematic commit d2c05f50e12f87128597a28146de7092aaa847c3:
>>>
>>> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
>>> index 8636cd713a..dc26e54795 100644
>>> --- a/drivers/mmc/omap_hsmmc.c
>>> +++ b/drivers/mmc/omap_hsmmc.c
>>> @@ -840,7 +840,7 @@ static int omap_hsmmc_init_setup(struct mmc *mmc)
>>>  	omap_hsmmc_conf_bus_power(mmc, (reg_val & VS33_3V3SUP) ?
>>>  			  MMC_SIGNAL_VOLTAGE_330 : MMC_SIGNAL_VOLTAGE_180);
>>>  #else
>>> -	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, &mmc_base->hctl);
>>> +	writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V3, &mmc_base->hctl);
>>>  	writel(readl(&mmc_base->capa) | VS33_3V3SUP | VS18_1V8SUP,
>>>  		&mmc_base->capa);
>>>  #endif
>>>
>>> So eMMC on real N900 is working fine either with 3.0V or 3.3V. But 3.3V
>>> needs to be configured on all places.
>>
>> Hello! Could you please take a look at this issue and my above fix?
> 
> Ping. Any comment for above issue or my fix?
> 

Sorry I missed this earlier. The fix makes sense to me. I can give my reviewed
by to the your fix once you send the patch.

Thanks,
Faiz

Bisected: mmc cause reboot loops on N900

[Pali Rohár]

Pavel suggested to add Tomi into the loop as Jean is not with TI anymore.

Tomi, could you please look at this mmc related problem? See details below.

On Sunday 26 April 2020 00:20:07 Pali Roh?r wrote:
> On Saturday 25 April 2020 23:26:15 Pali Roh?r wrote:
> > Adding Jean to the loop. Could you please look at this problem? Your
> > commit (described below) is causing reboot loop on Nokia N900 hardware.
> > 
> > On Saturday 25 April 2020 13:50:45 Pali Roh?r wrote:
> > > On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
> > > > On Sat, Apr 25, 2020 at 5:42 AM Pali Roh?r <pali@kernel.org> wrote:
> > > > >
> > > > > On Thursday 02 April 2020 20:42:31 Pali Roh?r wrote:
> > > > > > On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> > ...
> > > > > > > U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> > > > > > >
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > > Nokia RX-51 + LPDDR/OneNAND
> > > > > > > I2C:   ready
> > > > > > > DRAM:  256 MiB
> > > > > > > NAND:  0 Bytes
> > ...
> > > > > > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > ...
> > > > > > > OMAP die ID: 031400240000000004036ac10b01100f
> > > > > > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> > > > > > >
> > > > > >
> > > > > > And then U-Boot freeze, right?
> > > > > >
> > > > > > Any idea how to debug this issue?
> > > > > >
> > > > > > On my N900 I'm getting "data abort" error on display and then instant
> > > > > > reboot.
> > > > >
> > > > > It looks like that omap hs mmc code cause that freeze/reboot on real HW.
> > > > > Was there some significat change to OMAP3 or omap hs mmc?
> > > > 
> > > > I booted by board from MMC as shown above.  I also use the pinctrl
> > > > features from the device tree to mux the pins in U-Boot (not SPL), so
> > > > my SPL only does manual muxing the essential components it needs
> > > > during the SPL phase, and lets U-Boot do the rest.   I only  mention
> > > > the pinmux because of message regarding pads/pull-ups.
> > > > 
> > > > adam
> > > 
> > > I debugged this problem more. I disabled all preboot commands to get
> > > clean U-Boot setup. And it worked.
> > > 
> > > After I called any "mmc" command (e.g. "mmc info") I got that instant
> > > board reboot. Preboot commands for n900 try to read some files from mmc,
> > > so this is reason why it get into reboot loop.
> > > 
> > > Is there any reason why "mmc info" command can cause "data abort" and
> > > instant reboot of board?
> > > 
> > > And do you know what is needed for proper initialization of omap mmc
> > > controller for omap3 board? Because it looks like something fundamental
> > > is missing.
> > > 
> > > Currently there are just calls for "omap_mmc_init()" functions and
> > > "twl4030_power_mmc_init()" functions. See:
> > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/nokia/rx51/rx51.c
> > 
> > Now I tried git bisect and here is problematic commit which caused whole
> > reboot loop:
> > 
> > 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 is the first bad commit
> > commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355
> > Author: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > Date:   Thu Sep 21 16:30:08 2017 +0200
> > 
> >     mmc: disable UHS modes if Vcc cannot be switched on and off
> >     
> >     If a power cycle cannot be done on Vcc, it is safer not to try the UHS
> >     modes because we wouldn't be able to recover from an error occurring
> >     during the UHS initialization.
> >     
> >     Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > 
> > :040000 040000 04de51428c8311a4b2fb3ad876ac3f6071ab57ee ea7a7959a4bd591c92a2c3d413d5643a8457d2ff M      drivers
> > :040000 040000 03f639baf2a2f55003cb750981fd8accc5b4a993 fbcb9607d37959f0b5240f5d727133f58cc35379 M      include
> > 
> > It changes only core mmc code, nothing platform / board specific.
> > U-Boot compiled from commit before above has fully working eMMC access
> > on real Nokia N900. I can read files on FAT eMMC partition without any
> > problem.
> > 
> > I'm not sure what is happening here, but it looks like that omap hs mmc
> > driver used on Nokia N900 is maybe not correctly hooked for UHS support.
> > 
> > The most suspicious it that this problem cannot be reproduced in qemu
> > n900 emulator. It happens only on real N900 hw.
> 
> I took main change from above commit, reverted it on master and U-Boot
> stopped crashing! No reboot loop anymore. Here is change which fixes
> reboot loop on Nokia N900:
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 523c055967..d07c7745da 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2786,18 +2786,7 @@ int mmc_get_op_cond(struct mmc *mmc)
>  		      MMC_QUIRK_RETRY_APP_CMD;
>  #endif
>  
> -	err = mmc_power_cycle(mmc);
> -	if (err) {
> -		/*
> -		 * if power cycling is not supported, we should not try
> -		 * to use the UHS modes, because we wouldn't be able to
> -		 * recover from an error during the UHS initialization.
> -		 */
> -		pr_debug("Unable to do a full power cycle. Disabling the UHS modes for safety\n");
> -		uhs_en = false;
> -		mmc->host_caps &= ~UHS_CAPS;
> -		err = mmc_power_on(mmc);
> -	}
> +	err = mmc_power_on(mmc);
>  	if (err)
>  		return err;
>  
> 
> Jean, do you have any idea what is happening in above code? It looks
> like something is broken in power cycle / power on sequence if it cause
> "data abort" and reboot of board.

Bisected: mmc cause reboot loops on N900 (Was: Re: U-Boot is broken on real N900 HW)

[Pavel Machek]

Hi!

> Adding Jean to the loop. Could you please look at this problem? Your
> commit (described below) is causing reboot loop on Nokia N900
> hardware.

I'm not sure Jean is still with TI. You may want to talk to Tomi
Valkeinen <tomi.valkeinen@ti.com> if you don't get replies.

Best regards,
								Pavel

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200426/50e27e31/attachment.sig>

U-Boot is broken on real N900 HW (Was: Re: [PATCH 00/11] Fixes for Nokia RX-51)

[Pavel Machek]

On Wed 2020-04-01 00:42:54, Pali Roh??r wrote:
> On Wednesday 01 April 2020 00:35:07 Pali Roh??r wrote:
> > This patch series contain fixes for Nokia RX-51 board (aka N900).
> > After these changes it is possible to run U-Boot in qemu emulator again.
> > And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > problem.
> 
> But on real Nokia N900 device is U-Boot crashing in reboot loop.
> 
> I do not have serial console for Nokia N900 to debug this issue, but
> seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> that there is no crash and even no error in qemu emulator so I cannot
> debug this issue.

I have a serial cable I do not currently need. Would it help? 

Best regards,
								Pavel
								
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

U-Boot is broken on real N900 HW (Was: Re: [PATCH 00/11] Fixes for Nokia RX-51)

[Pali Rohár]

On Monday 06 April 2020 22:12:33 Pavel Machek wrote:
> On Wed 2020-04-01 00:42:54, Pali Roh??r wrote:
> > On Wednesday 01 April 2020 00:35:07 Pali Roh??r wrote:
> > > This patch series contain fixes for Nokia RX-51 board (aka N900).
> > > After these changes it is possible to run U-Boot in qemu emulator again.
> > > And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > > problem.
> > 
> > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > 
> > I do not have serial console for Nokia N900 to debug this issue, but
> > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > that there is no crash and even no error in qemu emulator so I cannot
> > debug this issue.
> 
> I have a serial cable I do not currently need. Would it help? 

Merlijn already posted output from serial console, and from it looks
like U-Boot is crashing. I'm afraid I cannot debug it even with serial
console as I do not know how what was e.g. changed in U-Boot that I2C
stopped working or why U-Boot crashes on real HW, but in qemu there is
not problem...

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> This patch series contain fixes for Nokia RX-51 board (aka N900).
> After these changes it is possible to run U-Boot in qemu emulator again.
> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> problem.
> 
> Pali Roh?r (11):
>   Nokia RX-51: Update my email address
>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>   Nokia RX-51: Move code from defconfig back to C header file
>   Nokia RX-51: Revert back onenand defitions
>   Nokia RX-51: Remove PART* macros
>   Nokia RX-51: Remember setup_console_atag option
>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>     binary
>   Nokia RX-51: Update README.nokia_rx51
>   Nokia RX-51: Add automated test for running RX-51 build in qemu

Hello! Could you please review this patch series?

>  .travis.yml                      |  10 ++
>  board/nokia/rx51/MAINTAINERS     |   3 +-
>  board/nokia/rx51/lowlevel_init.S |  11 +-
>  board/nokia/rx51/rx51.c          |  43 ++++---
>  board/nokia/rx51/rx51.h          |   2 +-
>  board/nokia/rx51/tag_omap.h      |   4 +-
>  cmd/bootmenu.c                   |   2 +-
>  configs/nokia_rx51_defconfig     |  27 +++-
>  doc/README.bootmenu              |   2 +-
>  doc/README.nokia_rx51            |  32 +++--
>  include/ansi.h                   |   2 +-
>  include/configs/nokia_rx51.h     |  88 ++++---------
>  test/rx51_test.sh                | 208 +++++++++++++++++++++++++++++++
>  13 files changed, 327 insertions(+), 107 deletions(-)
>  create mode 100755 test/rx51_test.sh
> 
> -- 
> 2.20.1
> 

[PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 13/04/20 4:11 PM, Pali Roh?r wrote:
> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>> After these changes it is possible to run U-Boot in qemu emulator again.
>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>> problem.
>>
>> Pali Roh?r (11):
>>   Nokia RX-51: Update my email address
>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>   Nokia RX-51: Move code from defconfig back to C header file
>>   Nokia RX-51: Revert back onenand defitions
>>   Nokia RX-51: Remove PART* macros
>>   Nokia RX-51: Remember setup_console_atag option
>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>     binary
>>   Nokia RX-51: Update README.nokia_rx51
>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> 
> Hello! Could you please review this patch series?

Series as such looks good to me. But as I see that thread, this series could not
boot on real hardware. Is that right?

Thanks and regards,
Lokesh

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> On 13/04/20 4:11 PM, Pali Roh?r wrote:
> > On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >> After these changes it is possible to run U-Boot in qemu emulator again.
> >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >> problem.
> >>
> >> Pali Roh?r (11):
> >>   Nokia RX-51: Update my email address
> >>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> >>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> >>   Nokia RX-51: Move code from defconfig back to C header file
> >>   Nokia RX-51: Revert back onenand defitions
> >>   Nokia RX-51: Remove PART* macros
> >>   Nokia RX-51: Remember setup_console_atag option
> >>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> >>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> >>     binary
> >>   Nokia RX-51: Update README.nokia_rx51
> >>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> > 
> > Hello! Could you please review this patch series?
> 
> Series as such looks good to me. But as I see that thread, this series could not
> boot on real hardware. Is that right?

Without these patches U-Boot does not boot on both emulated and real HW.
With this patch series U-Boot boots at least on emulated env.

Older mainline U-Boot version worked fine on both emulated and real HW
so something was broken in U-Boot.

> Thanks and regards,
> Lokesh

[PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 14/04/20 4:01 PM, Pali Roh?r wrote:
> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>> problem.
>>>>
>>>> Pali Roh?r (11):
>>>>   Nokia RX-51: Update my email address
>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>>>   Nokia RX-51: Move code from defconfig back to C header file
>>>>   Nokia RX-51: Revert back onenand defitions
>>>>   Nokia RX-51: Remove PART* macros
>>>>   Nokia RX-51: Remember setup_console_atag option
>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>>>     binary
>>>>   Nokia RX-51: Update README.nokia_rx51
>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
>>>
>>> Hello! Could you please review this patch series?
>>
>> Series as such looks good to me. But as I see that thread, this series could not
>> boot on real hardware. Is that right?
> 
> Without these patches U-Boot does not boot on both emulated and real HW.
> With this patch series U-Boot boots at least on emulated env.
> 
> Older mainline U-Boot version worked fine on both emulated and real HW
> so something was broken in U-Boot.

So the issue is not completely fixed. Can we get the fix for real hardware
included in this series?

Thanks and regards,
Lokesh

> 
>> Thanks and regards,
>> Lokesh

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
> On 14/04/20 4:01 PM, Pali Roh?r wrote:
> > On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> >> On 13/04/20 4:11 PM, Pali Roh?r wrote:
> >>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> >>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >>>> After these changes it is possible to run U-Boot in qemu emulator again.
> >>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >>>> problem.
> >>>>
> >>>> Pali Roh?r (11):
> >>>>   Nokia RX-51: Update my email address
> >>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> >>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> >>>>   Nokia RX-51: Move code from defconfig back to C header file
> >>>>   Nokia RX-51: Revert back onenand defitions
> >>>>   Nokia RX-51: Remove PART* macros
> >>>>   Nokia RX-51: Remember setup_console_atag option
> >>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> >>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> >>>>     binary
> >>>>   Nokia RX-51: Update README.nokia_rx51
> >>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> >>>
> >>> Hello! Could you please review this patch series?
> >>
> >> Series as such looks good to me. But as I see that thread, this series could not
> >> boot on real hardware. Is that right?
> > 
> > Without these patches U-Boot does not boot on both emulated and real HW.
> > With this patch series U-Boot boots at least on emulated env.
> > 
> > Older mainline U-Boot version worked fine on both emulated and real HW
> > so something was broken in U-Boot.
> 
> So the issue is not completely fixed. Can we get the fix for real hardware
> included in this series?

I do not have hw equipment for debugging nor I do not know what happened
that U-Boot stopped working. I already asked for help what happened with
omap i2c code in u-boot that stopped working but nobody answered me yet.

[PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 14/04/20 4:47 PM, Pali Roh?r wrote:
> On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
>> On 14/04/20 4:01 PM, Pali Roh?r wrote:
>>> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
>>>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>> problem.
>>>>>>
>>>>>> Pali Roh?r (11):
>>>>>>   Nokia RX-51: Update my email address
>>>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>>>>>   Nokia RX-51: Move code from defconfig back to C header file
>>>>>>   Nokia RX-51: Revert back onenand defitions
>>>>>>   Nokia RX-51: Remove PART* macros
>>>>>>   Nokia RX-51: Remember setup_console_atag option
>>>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>>>>>     binary
>>>>>>   Nokia RX-51: Update README.nokia_rx51
>>>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
>>>>>
>>>>> Hello! Could you please review this patch series?
>>>>
>>>> Series as such looks good to me. But as I see that thread, this series could not
>>>> boot on real hardware. Is that right?
>>>
>>> Without these patches U-Boot does not boot on both emulated and real HW.
>>> With this patch series U-Boot boots at least on emulated env.
>>>
>>> Older mainline U-Boot version worked fine on both emulated and real HW
>>> so something was broken in U-Boot.
>>
>> So the issue is not completely fixed. Can we get the fix for real hardware
>> included in this series?
> 
> I do not have hw equipment for debugging nor I do not know what happened
> that U-Boot stopped working. I already asked for help what happened with
> omap i2c code in u-boot that stopped working but nobody answered me yet.

I don;t know when it stopped working. But I2C has migrated to Driver-Model. Did
you check if DM_I2C is enabled for nokia rx-51?

Thanks and regards,
Lokesh

> 

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Tuesday 14 April 2020 17:21:24 Lokesh Vutla wrote:
> On 14/04/20 4:47 PM, Pali Roh?r wrote:
> > On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
> >> On 14/04/20 4:01 PM, Pali Roh?r wrote:
> >>> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> >>>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
> >>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> >>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
> >>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >>>>>> problem.
> >>>>>>
> >>>>>> Pali Roh?r (11):
> >>>>>>   Nokia RX-51: Update my email address
> >>>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> >>>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> >>>>>>   Nokia RX-51: Move code from defconfig back to C header file
> >>>>>>   Nokia RX-51: Revert back onenand defitions
> >>>>>>   Nokia RX-51: Remove PART* macros
> >>>>>>   Nokia RX-51: Remember setup_console_atag option
> >>>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> >>>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> >>>>>>     binary
> >>>>>>   Nokia RX-51: Update README.nokia_rx51
> >>>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> >>>>>
> >>>>> Hello! Could you please review this patch series?
> >>>>
> >>>> Series as such looks good to me. But as I see that thread, this series could not
> >>>> boot on real hardware. Is that right?
> >>>
> >>> Without these patches U-Boot does not boot on both emulated and real HW.
> >>> With this patch series U-Boot boots at least on emulated env.
> >>>
> >>> Older mainline U-Boot version worked fine on both emulated and real HW
> >>> so something was broken in U-Boot.
> >>
> >> So the issue is not completely fixed. Can we get the fix for real hardware
> >> included in this series?
> > 
> > I do not have hw equipment for debugging nor I do not know what happened
> > that U-Boot stopped working. I already asked for help what happened with
> > omap i2c code in u-boot that stopped working but nobody answered me yet.
> 
> I don;t know when it stopped working. But I2C has migrated to Driver-Model. Did
> you check if DM_I2C is enabled for nokia rx-51?

In .config I do not see any DM_I2C string. Should I something enable?
What is needed for OMAP I2C? In .config is:

CONFIG_SYS_I2C_OMAP24XX=y
CONFIG_SYS_OMAP24_I2C_SLAVE=1
CONFIG_SYS_OMAP24_I2C_SPEED=100000
CONFIG_SYS_I2C_BUS_MAX=3

But strange is that there is no problem in qemu emulator without any
crash.

> Thanks and regards,
> Lokesh
> 
> > 

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Tuesday 14 April 2020 14:01:44 Pali Roh?r wrote:
> On Tuesday 14 April 2020 17:21:24 Lokesh Vutla wrote:
> > On 14/04/20 4:47 PM, Pali Roh?r wrote:
> > > On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
> > >> On 14/04/20 4:01 PM, Pali Roh?r wrote:
> > >>> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> > >>>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
> > >>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> > >>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
> > >>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
> > >>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> > >>>>>> problem.
> > >>>>>>
> > >>>>>> Pali Roh?r (11):
> > >>>>>>   Nokia RX-51: Update my email address
> > >>>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> > >>>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> > >>>>>>   Nokia RX-51: Move code from defconfig back to C header file
> > >>>>>>   Nokia RX-51: Revert back onenand defitions
> > >>>>>>   Nokia RX-51: Remove PART* macros
> > >>>>>>   Nokia RX-51: Remember setup_console_atag option
> > >>>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> > >>>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> > >>>>>>     binary
> > >>>>>>   Nokia RX-51: Update README.nokia_rx51
> > >>>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> > >>>>>
> > >>>>> Hello! Could you please review this patch series?
> > >>>>
> > >>>> Series as such looks good to me. But as I see that thread, this series could not
> > >>>> boot on real hardware. Is that right?
> > >>>
> > >>> Without these patches U-Boot does not boot on both emulated and real HW.
> > >>> With this patch series U-Boot boots at least on emulated env.
> > >>>
> > >>> Older mainline U-Boot version worked fine on both emulated and real HW
> > >>> so something was broken in U-Boot.
> > >>
> > >> So the issue is not completely fixed. Can we get the fix for real hardware
> > >> included in this series?
> > > 
> > > I do not have hw equipment for debugging nor I do not know what happened
> > > that U-Boot stopped working. I already asked for help what happened with
> > > omap i2c code in u-boot that stopped working but nobody answered me yet.
> > 
> > I don;t know when it stopped working. But I2C has migrated to Driver-Model. Did
> > you check if DM_I2C is enabled for nokia rx-51?
> 
> In .config I do not see any DM_I2C string. Should I something enable?
> What is needed for OMAP I2C? In .config is:
> 
> CONFIG_SYS_I2C_OMAP24XX=y
> CONFIG_SYS_OMAP24_I2C_SLAVE=1
> CONFIG_SYS_OMAP24_I2C_SPEED=100000
> CONFIG_SYS_I2C_BUS_MAX=3

I tried to enable CONFIG_DM and CONFIG_DM_I2C, but it threw following errors:

  GEN     include/autoconf.mk.dep
In file included from include/config.h:8,
                 from ./include/common.h:16:
include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
 #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
    ^~~~~
In file included from include/config.h:8,
                 from ./include/common.h:16:
include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
 #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
    ^~~~~

Next I tried to remove CONFIG_SYS_I2C from include/configs/nokia_rx51.h but it threw another error:

board/nokia/rx51/rx51.c: In function ?rx51_kp_tstc?:
board/nokia/rx51/rx51.c:628:3: warning: implicit declaration of function ?i2c_read?; did you mean ?mmc_read?? [-Wimplicit-function-declaration]
   i2c_read(TWL4030_CHIP_KEYPAD,
   ^~~~~~~~
   mmc_read

arm-linux-gnueabi-ld.bfd: board/nokia/rx51/built-in.o: in function `rx51_kp_tstc':
/home/pali/develop/u-boot/u-boot/board/nokia/rx51/rx51.c:628: undefined reference to `i2c_read'

So looks like that CONFIG_DM_I2C is not possible to use it right now.

> But strange is that there is no problem in qemu emulator without any
> crash.
> 
> > Thanks and regards,
> > Lokesh
> > 
> > > 

[PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 17/04/20 3:27 AM, Pali Roh?r wrote:
> On Tuesday 14 April 2020 14:01:44 Pali Roh?r wrote:
>> On Tuesday 14 April 2020 17:21:24 Lokesh Vutla wrote:
>>> On 14/04/20 4:47 PM, Pali Roh?r wrote:
>>>> On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
>>>>> On 14/04/20 4:01 PM, Pali Roh?r wrote:
>>>>>> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
>>>>>>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
>>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> Pali Roh?r (11):
>>>>>>>>>   Nokia RX-51: Update my email address
>>>>>>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>>>>>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>>>>>>>>   Nokia RX-51: Move code from defconfig back to C header file
>>>>>>>>>   Nokia RX-51: Revert back onenand defitions
>>>>>>>>>   Nokia RX-51: Remove PART* macros
>>>>>>>>>   Nokia RX-51: Remember setup_console_atag option
>>>>>>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>>>>>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>>>>>>>>     binary
>>>>>>>>>   Nokia RX-51: Update README.nokia_rx51
>>>>>>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
>>>>>>>>
>>>>>>>> Hello! Could you please review this patch series?
>>>>>>>
>>>>>>> Series as such looks good to me. But as I see that thread, this series could not
>>>>>>> boot on real hardware. Is that right?
>>>>>>
>>>>>> Without these patches U-Boot does not boot on both emulated and real HW.
>>>>>> With this patch series U-Boot boots at least on emulated env.
>>>>>>
>>>>>> Older mainline U-Boot version worked fine on both emulated and real HW
>>>>>> so something was broken in U-Boot.
>>>>>
>>>>> So the issue is not completely fixed. Can we get the fix for real hardware
>>>>> included in this series?
>>>>
>>>> I do not have hw equipment for debugging nor I do not know what happened
>>>> that U-Boot stopped working. I already asked for help what happened with
>>>> omap i2c code in u-boot that stopped working but nobody answered me yet.
>>>
>>> I don;t know when it stopped working. But I2C has migrated to Driver-Model. Did
>>> you check if DM_I2C is enabled for nokia rx-51?
>>
>> In .config I do not see any DM_I2C string. Should I something enable?
>> What is needed for OMAP I2C? In .config is:
>>
>> CONFIG_SYS_I2C_OMAP24XX=y
>> CONFIG_SYS_OMAP24_I2C_SLAVE=1
>> CONFIG_SYS_OMAP24_I2C_SPEED=100000
>> CONFIG_SYS_I2C_BUS_MAX=3
> 
> I tried to enable CONFIG_DM and CONFIG_DM_I2C, but it threw following errors:
> 
>   GEN     include/autoconf.mk.dep
> In file included from include/config.h:8,
>                  from ./include/common.h:16:
> include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
>  #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
>     ^~~~~
> In file included from include/config.h:8,
>                  from ./include/common.h:16:
> include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
>  #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
>     ^~~~~
> 
> Next I tried to remove CONFIG_SYS_I2C from include/configs/nokia_rx51.h but it threw another error:
> 
> board/nokia/rx51/rx51.c: In function ?rx51_kp_tstc?:
> board/nokia/rx51/rx51.c:628:3: warning: implicit declaration of function ?i2c_read?; did you mean ?mmc_read?? [-Wimplicit-function-declaration]
>    i2c_read(TWL4030_CHIP_KEYPAD,

I guess it should be dm_i2c_read(). Also do you have plat_data or DT enabled on
your board? I mean either of those are needed to probe the driver.

Thanks and regards,
Lokesh

>    ^~~~~~~~
>    mmc_read
> 
> arm-linux-gnueabi-ld.bfd: board/nokia/rx51/built-in.o: in function `rx51_kp_tstc':
> /home/pali/develop/u-boot/u-boot/board/nokia/rx51/rx51.c:628: undefined reference to `i2c_read'
> 
> So looks like that CONFIG_DM_I2C is not possible to use it right now.
> 
>> But strange is that there is no problem in qemu emulator without any
>> crash.
>>
>>> Thanks and regards,
>>> Lokesh
>>>
>>>>

[PATCH 00/11] Fixes for Nokia RX-51

[Pali Rohár]

On Monday 20 April 2020 13:42:12 Lokesh Vutla wrote:
> 
> 
> On 17/04/20 3:27 AM, Pali Roh?r wrote:
> > On Tuesday 14 April 2020 14:01:44 Pali Roh?r wrote:
> >> On Tuesday 14 April 2020 17:21:24 Lokesh Vutla wrote:
> >>> On 14/04/20 4:47 PM, Pali Roh?r wrote:
> >>>> On Tuesday 14 April 2020 16:14:08 Lokesh Vutla wrote:
> >>>>> On 14/04/20 4:01 PM, Pali Roh?r wrote:
> >>>>>> On Tuesday 14 April 2020 15:53:14 Lokesh Vutla wrote:
> >>>>>>> On 13/04/20 4:11 PM, Pali Roh?r wrote:
> >>>>>>>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
> >>>>>>>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >>>>>>>>> After these changes it is possible to run U-Boot in qemu emulator again.
> >>>>>>>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >>>>>>>>> problem.
> >>>>>>>>>
> >>>>>>>>> Pali Roh?r (11):
> >>>>>>>>>   Nokia RX-51: Update my email address
> >>>>>>>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
> >>>>>>>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
> >>>>>>>>>   Nokia RX-51: Move code from defconfig back to C header file
> >>>>>>>>>   Nokia RX-51: Revert back onenand defitions
> >>>>>>>>>   Nokia RX-51: Remove PART* macros
> >>>>>>>>>   Nokia RX-51: Remember setup_console_atag option
> >>>>>>>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
> >>>>>>>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
> >>>>>>>>>     binary
> >>>>>>>>>   Nokia RX-51: Update README.nokia_rx51
> >>>>>>>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
> >>>>>>>>
> >>>>>>>> Hello! Could you please review this patch series?
> >>>>>>>
> >>>>>>> Series as such looks good to me. But as I see that thread, this series could not
> >>>>>>> boot on real hardware. Is that right?
> >>>>>>
> >>>>>> Without these patches U-Boot does not boot on both emulated and real HW.
> >>>>>> With this patch series U-Boot boots at least on emulated env.
> >>>>>>
> >>>>>> Older mainline U-Boot version worked fine on both emulated and real HW
> >>>>>> so something was broken in U-Boot.
> >>>>>
> >>>>> So the issue is not completely fixed. Can we get the fix for real hardware
> >>>>> included in this series?
> >>>>
> >>>> I do not have hw equipment for debugging nor I do not know what happened
> >>>> that U-Boot stopped working. I already asked for help what happened with
> >>>> omap i2c code in u-boot that stopped working but nobody answered me yet.
> >>>
> >>> I don;t know when it stopped working. But I2C has migrated to Driver-Model. Did
> >>> you check if DM_I2C is enabled for nokia rx-51?
> >>
> >> In .config I do not see any DM_I2C string. Should I something enable?
> >> What is needed for OMAP I2C? In .config is:
> >>
> >> CONFIG_SYS_I2C_OMAP24XX=y
> >> CONFIG_SYS_OMAP24_I2C_SLAVE=1
> >> CONFIG_SYS_OMAP24_I2C_SPEED=100000
> >> CONFIG_SYS_I2C_BUS_MAX=3
> > 
> > I tried to enable CONFIG_DM and CONFIG_DM_I2C, but it threw following errors:
> > 
> >   GEN     include/autoconf.mk.dep
> > In file included from include/config.h:8,
> >                  from ./include/common.h:16:
> > include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
> >  #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
> >     ^~~~~
> > In file included from include/config.h:8,
> >                  from ./include/common.h:16:
> > include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
> >  #  error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used"
> >     ^~~~~
> > 
> > Next I tried to remove CONFIG_SYS_I2C from include/configs/nokia_rx51.h but it threw another error:
> > 
> > board/nokia/rx51/rx51.c: In function ?rx51_kp_tstc?:
> > board/nokia/rx51/rx51.c:628:3: warning: implicit declaration of function ?i2c_read?; did you mean ?mmc_read?? [-Wimplicit-function-declaration]
> >    i2c_read(TWL4030_CHIP_KEYPAD,
> 
> I guess it should be dm_i2c_read(). Also do you have plat_data or DT enabled on
> your board? I mean either of those are needed to probe the driver.

Ok, it looks like this is irrelevant to mentioned problem as it is
working in qemu emulator.

So is something else needed to do in this patch series?

> Thanks and regards,
> Lokesh
> 
> >    ^~~~~~~~
> >    mmc_read
> > 
> > arm-linux-gnueabi-ld.bfd: board/nokia/rx51/built-in.o: in function `rx51_kp_tstc':
> > /home/pali/develop/u-boot/u-boot/board/nokia/rx51/rx51.c:628: undefined reference to `i2c_read'
> > 
> > So looks like that CONFIG_DM_I2C is not possible to use it right now.
> > 
> >> But strange is that there is no problem in qemu emulator without any
> >> crash.
> >>
> >>> Thanks and regards,
> >>> Lokesh
> >>>
> >>>>

[PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 14/04/20 3:53 PM, Lokesh Vutla wrote:
> 
> 
> On 13/04/20 4:11 PM, Pali Roh?r wrote:
>> On Wednesday 01 April 2020 00:35:07 Pali Roh?r wrote:
>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>> problem.
>>>
>>> Pali Roh?r (11):
>>>   Nokia RX-51: Update my email address
>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>>   Nokia RX-51: Move code from defconfig back to C header file
>>>   Nokia RX-51: Revert back onenand defitions
>>>   Nokia RX-51: Remove PART* macros
>>>   Nokia RX-51: Remember setup_console_atag option
>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>>     binary
>>>   Nokia RX-51: Update README.nokia_rx51
>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
>>
>> Hello! Could you please review this patch series?
> 
> Series as such looks good to me. But as I see that thread, this series could not
> boot on real hardware. Is that right?
> 
> Thanks and regards,
> Lokesh
> 

Except PATCH 11, series Merged into u-boot-ti.

Thanks and regards,
Lokesh