[PATCH] arm: Remove nokia_rx51 board

[PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

This board has not been converted to CONFIG_DM_USB by the deadline.
Remove it.

Cc: Pali Roh?r <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
I assume you'll be trying to fix this so I've not removed all of the
test related scripts.
---
 .azure-pipelines.yml              |  13 -
 .gitlab-ci.yml                    |   7 -
 arch/arm/mach-omap2/omap3/Kconfig |   4 -
 board/nokia/rx51/Kconfig          |  12 -
 board/nokia/rx51/MAINTAINERS      |   8 -
 board/nokia/rx51/Makefile         |   7 -
 board/nokia/rx51/lowlevel_init.S  | 196 --------
 board/nokia/rx51/rx51.c           | 724 ------------------------------
 board/nokia/rx51/tag_omap.h       | 294 ------------
 configs/nokia_rx51_defconfig      |  69 ---
 doc/README.nokia_rx51             |  94 ----
 include/configs/nokia_rx51.h      | 249 ----------
 test/nokia_rx51_test.sh           | 296 ------------
 13 files changed, 1973 deletions(-)
 delete mode 100644 board/nokia/rx51/Kconfig
 delete mode 100644 board/nokia/rx51/MAINTAINERS
 delete mode 100644 board/nokia/rx51/Makefile
 delete mode 100644 board/nokia/rx51/lowlevel_init.S
 delete mode 100644 board/nokia/rx51/rx51.c
 delete mode 100644 board/nokia/rx51/tag_omap.h
 delete mode 100644 configs/nokia_rx51_defconfig
 delete mode 100644 doc/README.nokia_rx51
 delete mode 100644 include/configs/nokia_rx51.h
 delete mode 100755 test/nokia_rx51_test.sh

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 438139660219..90d5e4dc7244 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -160,19 +160,6 @@ 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 5bf6f151b4fc..95aacdd9d74d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -163,13 +163,6 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
       ./tools/patman/patman test;
       make testconfig
 
-Run tests for Nokia RX-51 (aka N900):
-  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:
   variables:
diff --git a/arch/arm/mach-omap2/omap3/Kconfig b/arch/arm/mach-omap2/omap3/Kconfig
index 81c898b66e34..3c67a334d81c 100644
--- a/arch/arm/mach-omap2/omap3/Kconfig
+++ b/arch/arm/mach-omap2/omap3/Kconfig
@@ -105,9 +105,6 @@ config TARGET_OMAP3_LOGIC
 	select OMAP3_GPIO_6
 	imply CMD_DM
 
-config TARGET_NOKIA_RX51
-	bool "Nokia RX51"
-
 config TARGET_TAO3530
 	bool "TAO3530"
 	select OMAP3_GPIO_2
@@ -160,7 +157,6 @@ source "board/timll/devkit8000/Kconfig"
 source "board/ti/evm/Kconfig"
 source "board/isee/igep00x0/Kconfig"
 source "board/logicpd/omap3som/Kconfig"
-source "board/nokia/rx51/Kconfig"
 source "board/lg/sniper/Kconfig"
 
 endif
diff --git a/board/nokia/rx51/Kconfig b/board/nokia/rx51/Kconfig
deleted file mode 100644
index ec6a571a2263..000000000000
--- a/board/nokia/rx51/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_NOKIA_RX51
-
-config SYS_BOARD
-	default "rx51"
-
-config SYS_VENDOR
-	default "nokia"
-
-config SYS_CONFIG_NAME
-	default "nokia_rx51"
-
-endif
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
deleted file mode 100644
index 58b16bf9a95c..000000000000
--- a/board/nokia/rx51/MAINTAINERS
+++ /dev/null
@@ -1,8 +0,0 @@
-RX51 BOARD
-M:	Pali Roh?r <pali@kernel.org>
-S:	Maintained
-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/board/nokia/rx51/Makefile b/board/nokia/rx51/Makefile
deleted file mode 100644
index 842f9e6a650e..000000000000
--- a/board/nokia/rx51/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2000, 2001, 2002
-# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
-
-obj-y := rx51.o
-obj-y += lowlevel_init.o
diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S
deleted file mode 100644
index 1466d976fc4b..000000000000
--- a/board/nokia/rx51/lowlevel_init.S
+++ /dev/null
@@ -1,196 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2011-2012
- * Pali Roh?r <pali@kernel.org>
- */
-
-#include <config.h>
-
-relocaddr:		/* address of this relocaddr section after coping */
-	.word .		/* address of section (calculated at compile time) */
-
-startaddr:		/* address of u-boot after copying */
-	.word CONFIG_SYS_TEXT_BASE
-
-kernaddr:		/* address of kernel after copying */
-	.word KERNEL_ADDRESS
-
-kernsize:		/* maximal size of kernel image */
-	.word KERNEL_MAXSIZE
-
-kernoffs:		/* offset of kernel image in loaded u-boot */
-	.word KERNEL_OFFSET
-
-imagesize:		/* maximal size of image */
-	.word IMAGE_MAXSIZE
-
-ih_magic:		/* IH_MAGIC in big endian from include/image.h */
-	.word 0x56190527
-
-/*
- * Routine: save_boot_params (called after reset from start.S)
- * Description: Copy attached kernel to address KERNEL_ADDRESS
- *              Copy u-boot to address CONFIG_SYS_TEXT_BASE
- *              Return to copied u-boot address
- */
-
-.global save_boot_params
-save_boot_params:
-	/* Get return address */
-	ldr	lr, =save_boot_params_ret
-
-/* Copy valid attached kernel to address KERNEL_ADDRESS */
-
-copy_kernel_start:
-	adr	r0, relocaddr	/* r0 - address of section relocaddr */
-	ldr	r1, relocaddr	/* r1 - address of relocaddr after relocation */
-	cmp	r0, r1
-
-	/* r4 - calculated offset */
-	subhi	r4, r0, r1
-	sublo	r4, r1, r0
-
-	/* r0 - start of kernel before */
-	ldr	r0, startaddr
-	addhi	r0, r0, r4
-	sublo	r0, r0, r4
-	ldr	r1, kernoffs
-	add	r0, r0, r1
-
-	/* r3 - start of kernel after */
-	ldr	r3, kernaddr
-
-	/* r2 - end of kernel after */
-	ldr	r1, kernsize
-	add	r2, r3, r1
-
-	/* r1 - end of kernel before */
-	add	r1, r0, r1
-
-	/* remove header in target kernel */
-	mov	r5, #0
-	str	r5, [r3]
-
-	/* check for valid kernel uImage */
-	ldr	r4, [r0]	/* r4 - 4 bytes header of kernel */
-	ldr	r5, ih_magic	/* r5 - IH_MAGIC */
-	cmp	r4, r5
-	bne	copy_kernel_end	/* skip if invalid image */
-
-copy_kernel_loop:
-	ldmdb	r1!, {r3 - r10}
-	stmdb	r2!, {r3 - r10}
-	cmp	r1, r0
-	bhi	copy_kernel_loop
-
-copy_kernel_end:
-	mov	r5, #0
-	str	r5, [r0]	/* remove 4 bytes header of kernel */
-
-
-/* Fix u-boot code */
-
-fix_start:
-	adr	r0, relocaddr	/* r0 - address of section relocaddr */
-	ldr	r1, relocaddr	/* r1 - address of relocaddr after relocation */
-	cmp	r0, r1
-
-	beq	copy_uboot_end	/* skip if u-boot is on correct address */
-
-	/* r5 - calculated offset */
-	subhi	r5, r0, r1
-	sublo	r5, r1, r0
-
-	/* r6 - maximal u-boot size */
-	ldr	r6, imagesize
-
-	/* r1 - start of u-boot after */
-	ldr	r1, startaddr
-
-	/* r0 - start of u-boot before */
-	addhi	r0, r1, r5
-	sublo	r0, r1, r5
-
-	/* check if we need to move uboot copy code before calling it */
-	cmp	r5, r6
-	bhi	copy_uboot_start /* now coping u-boot code directly is safe */
-
-
-copy_code_start:
-	/* r0 - start of u-boot before */
-	/* r1 - start of u-boot after */
-	/* r6 - maximal u-boot size */
-
-	/* r7 - maximal kernel size */
-	ldr	r7, kernsize
-
-	/* r4 - end of kernel before */
-	add	r4, r0, r6
-	add	r4, r4, r7
-
-	/* r5 - end of u-boot after */
-	ldr	r5, startaddr
-	add	r5, r5, r6
-
-	/* r2 - start of loop code after */
-	cmp	r4, r5		/* higher address (r4 or r5) */
-	movhs	r2, r4
-	movlo	r2, r5
-
-	/* r3 - end of loop code before */
-	adr	r3, end
-
-	/* r4 - end of loop code after */
-	adr	r4, copy_uboot_start
-	sub	r4, r3, r4
-	add	r4, r2, r4
-
-copy_code_loop:
-	ldmdb	r3!, {r7 - r10}
-	stmdb	r4!, {r7 - r10}
-	cmp	r4, r2
-	bhi	copy_code_loop
-
-copy_code_end:
-	mov	pc, r2
-
-
-/*
- * 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 */
-	/* r1 - start of u-boot after */
-	/* r6 - maximal u-boot size */
-
-	/* r2 - end of u-boot after */
-	add	r2, r1, r6
-
-	/* condition for copying from left to right */
-	cmp	r0, r1
-	addlo	r1, r0, r6	/* r1 - end of u-boot before */
-	blo	copy_uboot_loop_right
-
-copy_uboot_loop_left:
-	ldmia	r0!, {r3 - r10}
-	stmia	r1!, {r3 - r10}
-	cmp	r1, r2
-	blo	copy_uboot_loop_left
-	b	copy_uboot_end
-
-copy_uboot_loop_right:
-	ldmdb	r1!, {r3 - r10}
-	stmdb	r2!, {r3 - r10}
-	cmp	r1, r0
-	bhi	copy_uboot_loop_right
-
-copy_uboot_end:
-	bx	lr
-
-end:
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
deleted file mode 100644
index 7bd5fbd71520..000000000000
--- a/board/nokia/rx51/rx51.c
+++ /dev/null
@@ -1,724 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2012
- * ?????? ???????? <freemangordon@abv.bg>
- *
- * (C) Copyright 2011-2012
- * Pali Roh?r <pali@kernel.org>
- *
- * (C) Copyright 2010
- * Alistair Buxton <a.j.buxton@gmail.com>
- *
- * Derived from Beagle Board and 3430 SDP code:
- * (C) Copyright 2004-2008
- * Texas Instruments, <www.ti.com>
- *
- * Author :
- *	Sunil Kumar <sunilsaini05@gmail.com>
- *	Shashi Ranjan <shashiranjanmca05@gmail.com>
- *
- *	Richard Woodruff <r-woodruff2@ti.com>
- *	Syed Mohammed Khasim <khasim@ti.com>
- */
-
-#include <common.h>
-#include <dm.h>
-#include <env.h>
-#include <init.h>
-#include <watchdog.h>
-#include <malloc.h>
-#include <twl4030.h>
-#include <i2c.h>
-#include <video_fb.h>
-#include <asm/global_data.h>
-#include <asm/io.h>
-#include <asm/setup.h>
-#include <asm/bitops.h>
-#include <asm/mach-types.h>
-#include <asm/omap_i2c.h>
-#include <asm/arch/mux.h>
-#include <asm/arch/sys_proto.h>
-#include <asm/arch/mmc_host_def.h>
-
-#include "tag_omap.h"
-
-/* Needed for ROM SMC call */
-struct emu_hal_params_rx51 {
-	u32 num_params;
-	u32 param1;
-	u32 param2;
-	u32 param3;
-	u32 param4;
-};
-
-#define ONENAND_GPMC_CONFIG1_RX51	0xfb001202
-#define ONENAND_GPMC_CONFIG2_RX51	0x00111100
-#define ONENAND_GPMC_CONFIG3_RX51	0x00020200
-#define ONENAND_GPMC_CONFIG4_RX51	0x11001102
-#define ONENAND_GPMC_CONFIG5_RX51	0x03101616
-#define ONENAND_GPMC_CONFIG6_RX51	0x90060000
-
-DECLARE_GLOBAL_DATA_PTR;
-
-GraphicDevice gdev;
-
-const omap3_sysinfo sysinfo = {
-	DDR_STACKED,
-	"Nokia RX-51",
-	"OneNAND"
-};
-
-/* This structure contains default omap tags needed for booting Maemo 5 */
-static struct tag_omap omap[] = {
-	OMAP_TAG_UART_CONFIG(0x04),
-	OMAP_TAG_SERIAL_CONSOLE_CONFIG(0x03, 0x01C200),
-	OMAP_TAG_LCD_CONFIG("acx565akm", "internal", 90, 0x18),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cam_focus", 0x44, 0x1, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cam_launch", 0x45, 0x1, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cam_shutter", 0x6e, 0x1, 0x0, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_apeslpx", 0x46, 0x2, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_bsi", 0x9d, 0x2, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_en", 0x4a, 0x2, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_rst", 0x4b, 0x6, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_rst_rq", 0x49, 0x6, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("cmt_wddis", 0x0d, 0x2, 0x2, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("headphone", 0xb1, 0x1, 0x1, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("kb_lock", 0x71, 0x1, 0x0, 0x0),
-	OMAP_TAG_GPIO_SWITCH_CONFIG("proximity", 0x59, 0x0, 0x0, 0x0),
-	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("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"),
-	OMAP_TAG_VERSION_STR_CONFIG("nolo", "1.4.14"),
-	OMAP_TAG_VERSION_STR_CONFIG("boot-mode", "normal"),
-	{ }
-};
-
-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
- * Description: Initialize pointers to values in tag_omap
- */
-static void init_omap_tags(void)
-{
-	char *component;
-	char *version;
-	int i = 0;
-	while (omap[i].hdr.tag) {
-		switch (omap[i].hdr.tag) {
-		case OMAP_TAG_BOOT_REASON:
-			boot_reason_ptr = omap[i].u.boot_reason.reason_str;
-			break;
-		case OMAP_TAG_VERSION_STR:
-			component = omap[i].u.version.component;
-			version = omap[i].u.version.version;
-			if (strcmp(component, "hw-build") == 0)
-				hw_build_ptr = version;
-			else if (strcmp(component, "nolo") == 0)
-				nolo_version_ptr = version;
-			else if (strcmp(component, "boot-mode") == 0)
-				boot_mode_ptr = version;
-			break;
-		default:
-			break;
-		}
-		i++;
-	}
-}
-
-static void reuse_omap_atags(struct tag_omap *t)
-{
-	char *component;
-	char *version;
-	while (t->hdr.tag) {
-		switch (t->hdr.tag) {
-		case OMAP_TAG_BOOT_REASON:
-			memset(boot_reason_ptr, 0, 12);
-			strcpy(boot_reason_ptr, t->u.boot_reason.reason_str);
-			break;
-		case OMAP_TAG_VERSION_STR:
-			component = t->u.version.component;
-			version = t->u.version.version;
-			if (strcmp(component, "hw-build") == 0) {
-				memset(hw_build_ptr, 0, 12);
-				strcpy(hw_build_ptr, version);
-			} else if (strcmp(component, "nolo") == 0) {
-				memset(nolo_version_ptr, 0, 12);
-				strcpy(nolo_version_ptr, version);
-			} else if (strcmp(component, "boot-mode") == 0) {
-				memset(boot_mode_ptr, 0, 12);
-				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;
-		}
-		t = tag_omap_next(t);
-	}
-}
-
-/*
- * Routine: reuse_atags
- * Description: Reuse atags from previous bootloader.
- *              Reuse only only HW build, boot reason, boot mode and nolo
- */
-static void reuse_atags(void)
-{
-	struct tag *t = (struct tag *)gd->bd->bi_boot_params;
-
-	/* First tag must be ATAG_CORE */
-	if (t->hdr.tag != ATAG_CORE)
-		return;
-
-	if (!boot_reason_ptr || !hw_build_ptr)
-		return;
-
-	/* Last tag must be ATAG_NONE */
-	while (t->hdr.tag != ATAG_NONE) {
-		switch (t->hdr.tag) {
-		case ATAG_REVISION:
-			memset(hw_build_ptr, 0, 12);
-			sprintf(hw_build_ptr, "%x", t->u.revision.rev);
-			break;
-		case ATAG_BOARD:
-			reuse_omap_atags((struct tag_omap *)&t->u);
-			break;
-		default:
-			break;
-		}
-		t = tag_next(t);
-	}
-}
-
-/*
- * Routine: board_init
- * Description: Early hardware init.
- */
-int board_init(void)
-{
-#if defined(CONFIG_CMD_ONENAND)
-	const u32 gpmc_regs_onenandrx51[GPMC_MAX_REG] = {
-		ONENAND_GPMC_CONFIG1_RX51,
-		ONENAND_GPMC_CONFIG2_RX51,
-		ONENAND_GPMC_CONFIG3_RX51,
-		ONENAND_GPMC_CONFIG4_RX51,
-		ONENAND_GPMC_CONFIG5_RX51,
-		ONENAND_GPMC_CONFIG6_RX51,
-		0
-	};
-#endif
-	/* in SRAM or SDRAM, finish GPMC */
-	gpmc_init();
-#if defined(CONFIG_CMD_ONENAND)
-	enable_gpmc_cs_config(gpmc_regs_onenandrx51, &gpmc_cfg->cs[0],
-			      CONFIG_SYS_ONENAND_BASE, GPMC_SIZE_256M);
-#endif
-	/* Enable the clks & power */
-	per_clocks_enable();
-	/* boot param addr */
-	gd->bd->bi_boot_params = OMAP34XX_SDRC_CS0 + 0x100;
-	return 0;
-}
-
-/*
- * Routine: get_board_revision
- * Description: Return board revision.
- */
-u32 get_board_rev(void)
-{
-	return simple_strtol(hw_build_ptr, NULL, 16);
-}
-
-/*
- * Routine: setup_board_tags
- * Description: Append board specific boot tags.
- */
-void setup_board_tags(struct tag **in_params)
-{
-	int setup_console_atag;
-	char *setup_boot_reason_atag;
-	char *setup_boot_mode_atag;
-	char *str;
-	int i;
-	int size;
-	int total_size;
-	struct tag *params;
-	struct tag_omap *t;
-
-	params = (struct tag *)gd->bd->bi_boot_params;
-
-	params->u.core.flags = 0x0;
-	params->u.core.pagesize = 0x1000;
-	params->u.core.rootdev = 0x0;
-
-	/* append omap atag only if env setup_omap_atag is set to 1 */
-	str = env_get("setup_omap_atag");
-	if (!str || str[0] != '1')
-		return;
-
-	str = env_get("setup_console_atag");
-	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");
-
-	params = *in_params;
-	t = (struct tag_omap *)&params->u;
-	total_size = sizeof(struct tag_header);
-
-	for (i = 0; omap[i].hdr.tag; i++) {
-
-		/* skip serial console tag */
-		if (!setup_console_atag &&
-			omap[i].hdr.tag == OMAP_TAG_SERIAL_CONSOLE)
-			continue;
-
-		size = omap[i].hdr.size + sizeof(struct tag_omap_header);
-		memcpy(t, &omap[i], size);
-
-		/* set uart tag to 0 - disable serial console */
-		if (!setup_console_atag && omap[i].hdr.tag == OMAP_TAG_UART)
-			t->u.uart.enabled_uarts = 0;
-
-		/* change boot reason */
-		if (setup_boot_reason_atag &&
-			omap[i].hdr.tag == OMAP_TAG_BOOT_REASON) {
-			memset(t->u.boot_reason.reason_str, 0, 12);
-			strcpy(t->u.boot_reason.reason_str,
-				setup_boot_reason_atag);
-		}
-
-		/* change boot mode */
-		if (setup_boot_mode_atag &&
-			omap[i].hdr.tag == OMAP_TAG_VERSION_STR &&
-			strcmp(omap[i].u.version.component, "boot-mode") == 0) {
-			memset(t->u.version.version, 0, 12);
-			strcpy(t->u.version.version, setup_boot_mode_atag);
-		}
-
-		total_size += size;
-		t = tag_omap_next(t);
-
-	}
-
-	params->hdr.tag = ATAG_BOARD;
-	params->hdr.size = total_size >> 2;
-	params = tag_next(params);
-
-	*in_params = params;
-}
-
-/*
- * Routine: video_hw_init
- * Description: Set up the GraphicDevice depending on sys_boot.
- */
-void *video_hw_init(void)
-{
-	/* fill in Graphic Device */
-	gdev.frameAdrs = 0x8f9c0000;
-	gdev.winSizeX = 800;
-	gdev.winSizeY = 480;
-	gdev.gdfBytesPP = 2;
-	gdev.gdfIndex = GDF_16BIT_565RGB;
-	memset((void *)gdev.frameAdrs, 0, 0xbb800);
-	return (void *) &gdev;
-}
-
-/*
- * Routine: twl4030_regulator_set_mode
- * Description: Set twl4030 regulator mode over i2c powerbus.
- */
-static void twl4030_regulator_set_mode(u8 id, u8 mode)
-{
-	u16 msg = MSG_SINGULAR(DEV_GRP_P1, id, mode);
-	twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER,
-			     TWL4030_PM_MASTER_PB_WORD_MSB, msg >> 8);
-	twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER,
-			     TWL4030_PM_MASTER_PB_WORD_LSB, msg & 0xff);
-}
-
-static void omap3_emu_romcode_call(u32 service_id, u32 *parameters)
-{
-	u32 i, num_params = *parameters;
-	u32 *sram_scratch_space = (u32 *)OMAP3_PUBLIC_SRAM_SCRATCH_AREA;
-
-	/*
-	 * copy the parameters to an un-cached area to avoid coherency
-	 * issues
-	 */
-	for (i = 0; i < num_params; i++) {
-		__raw_writel(*parameters, sram_scratch_space);
-		parameters++;
-		sram_scratch_space++;
-	}
-
-	/* Now make the PPA call */
-	do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
-}
-
-void omap3_set_aux_cr_secure(u32 acr)
-{
-	struct emu_hal_params_rx51 emu_romcode_params = { 0, };
-
-	emu_romcode_params.num_params = 2;
-	emu_romcode_params.param1 = acr;
-
-	omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
-			       (u32 *)&emu_romcode_params);
-}
-
-/*
- * Routine: omap3_update_aux_cr_secure_rx51
- * Description: Modify the contents Auxiliary Control Register.
- * Parameters:
- *   set_bits - bits to set in ACR
- *   clr_bits - bits to clear in ACR
- */
-static void omap3_update_aux_cr_secure_rx51(u32 set_bits, u32 clear_bits)
-{
-	u32 acr;
-
-	/* Read ACR */
-	asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
-	acr &= ~clear_bits;
-	acr |= set_bits;
-	omap3_set_aux_cr_secure(acr);
-}
-
-/*
- * Routine: misc_init_r
- * Description: Configure board specific parts.
- */
-int misc_init_r(void)
-{
-	struct udevice *dev;
-	char buf[12];
-	u8 state;
-
-	/* disable lp5523 led */
-	if (i2c_get_chip_for_busnum(1, 0x32, 1, &dev) == 0)
-		dm_i2c_reg_write(dev, 0x00, 0x00);
-
-	/* initialize twl4030 power managment */
-	twl4030_power_init();
-	twl4030_power_mmc_init(0);
-	twl4030_power_mmc_init(1);
-
-	/* set VSIM to 1.8V */
-	twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VSIM_DEDICATED,
-				TWL4030_PM_RECEIVER_VSIM_VSEL_18,
-				TWL4030_PM_RECEIVER_VSIM_DEV_GRP,
-				TWL4030_PM_RECEIVER_DEV_GRP_P1);
-
-	/* store I2C access state */
-	twl4030_i2c_read_u8(TWL4030_CHIP_PM_MASTER, TWL4030_PM_MASTER_PB_CFG,
-			    &state);
-
-	/* enable I2C access to powerbus (needed for twl4030 regulator) */
-	twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, TWL4030_PM_MASTER_PB_CFG,
-			     0x02);
-
-	/* set VAUX3, VSIM and VMMC1 state to active - enable eMMC memory */
-	twl4030_regulator_set_mode(RES_VAUX3, RES_STATE_ACTIVE);
-	twl4030_regulator_set_mode(RES_VSIM, RES_STATE_ACTIVE);
-	twl4030_regulator_set_mode(RES_VMMC1, RES_STATE_ACTIVE);
-
-	/* restore I2C access state */
-	twl4030_i2c_write_u8(TWL4030_CHIP_PM_MASTER, TWL4030_PM_MASTER_PB_CFG,
-			     state);
-
-	/* set env variable attkernaddr for relocated kernel */
-	sprintf(buf, "%#x", KERNEL_ADDRESS);
-	env_set("attkernaddr", buf);
-
-	/* initialize omap tags */
-	init_omap_tags();
-
-	/* reuse atags from previous bootloader */
-	reuse_atags();
-
-	omap_die_id_display();
-	print_cpuinfo();
-
-	/*
-	 * Cortex-A8(r1p0..r1p2) errata 430973 workaround
-	 * Set IBE bit in Auxiliary Control Register
-	 *
-	 * Call this routine only on real secure device
-	 * Qemu does not implement secure PPA and crash
-	 */
-	if (get_device_type() == HS_DEVICE)
-		omap3_update_aux_cr_secure_rx51(1 << 6, 0);
-
-	return 0;
-}
-
-static unsigned long int twl_wd_time; /* last time of watchdog reset */
-static unsigned long int twl_i2c_lock;
-
-/*
- * Routine: hw_watchdog_reset
- * Description: Reset timeout of twl4030 watchdog.
- */
-void hw_watchdog_reset(void)
-{
-	u8 timeout = 0;
-
-	/* do not reset watchdog too often - max every 4s */
-	if (get_timer(twl_wd_time) < 4 * CONFIG_SYS_HZ)
-		return;
-
-	/* localy lock twl4030 i2c bus */
-	if (test_and_set_bit(0, &twl_i2c_lock))
-		return;
-
-	/* read actual watchdog timeout */
-	twl4030_i2c_read_u8(TWL4030_CHIP_PM_RECEIVER,
-			    TWL4030_PM_RECEIVER_WATCHDOG_CFG, &timeout);
-
-	/* timeout 0 means watchdog is disabled */
-	/* reset watchdog timeout to 31s (maximum) */
-	if (timeout != 0)
-		twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER,
-				     TWL4030_PM_RECEIVER_WATCHDOG_CFG, 31);
-
-	/* store last watchdog reset time */
-	twl_wd_time = get_timer(0);
-
-	/* localy unlock twl4030 i2c bus */
-	test_and_clear_bit(0, &twl_i2c_lock);
-}
-
-/*
- * TWL4030 keypad handler for cfb_console
- */
-
-static const char keymap[] = {
-	/* normal */
-	'q',  'o',  'p',  ',', '\b',    0,  'a',  's',
-	'w',  'd',  'f',  'g',  'h',  'j',  'k',  'l',
-	'e',  '.',    0,  '\r',   0,  'z',  'x',  'c',
-	'r',  'v',  'b',  'n',  'm',  ' ',  ' ',    0,
-	't',    0,    0,    0,    0,    0,    0,    0,
-	'y',    0,    0,    0,    0,    0,    0,    0,
-	'u',    0,    0,    0,    0,    0,    0,    0,
-	'i',    5,    6,    0,    0,    0,    0,    0,
-	/* fn */
-	'1',  '9',  '0',  '=', '\b',    0,  '*',  '+',
-	'2',  '#',  '-',  '_',  '(',  ')',  '&',  '!',
-	'3',  '?',  '^', '\r',    0,  156,  '$',  238,
-	'4',  '/', '\\',  '"', '\'',  '@',    0,  '<',
-	'5',  '|',  '>',    0,    0,    0,    0,    0,
-	'6',    0,    0,    0,    0,    0,    0,    0,
-	'7',    0,    0,    0,    0,    0,    0,    0,
-	'8',   16,   17,    0,    0,    0,    0,    0,
-};
-
-static u8 keys[8];
-static u8 old_keys[8] = {0, 0, 0, 0, 0, 0, 0, 0};
-#define KEYBUF_SIZE 32
-static u8 keybuf[KEYBUF_SIZE];
-static u8 keybuf_head;
-static u8 keybuf_tail;
-
-/*
- * Routine: rx51_kp_init
- * Description: Initialize HW keyboard.
- */
-int rx51_kp_init(void)
-{
-	int ret = 0;
-	u8 ctrl;
-	ret = twl4030_i2c_read_u8(TWL4030_CHIP_KEYPAD,
-				  TWL4030_KEYPAD_KEYP_CTRL_REG, &ctrl);
-
-	if (ret)
-		return ret;
-
-	/* turn on keyboard and use hardware scanning */
-	ctrl |= TWL4030_KEYPAD_CTRL_KBD_ON;
-	ctrl |= TWL4030_KEYPAD_CTRL_SOFT_NRST;
-	ctrl |= TWL4030_KEYPAD_CTRL_SOFTMODEN;
-	ret |= twl4030_i2c_write_u8(TWL4030_CHIP_KEYPAD,
-				    TWL4030_KEYPAD_KEYP_CTRL_REG, ctrl);
-	/* enable key event status */
-	ret |= twl4030_i2c_write_u8(TWL4030_CHIP_KEYPAD,
-				    TWL4030_KEYPAD_KEYP_IMR1, 0xfe);
-	/* enable interrupt generation on rising and falling */
-	/* this is a workaround for qemu twl4030 emulation */
-	ret |= twl4030_i2c_write_u8(TWL4030_CHIP_KEYPAD,
-				    TWL4030_KEYPAD_KEYP_EDR, 0x57);
-	/* enable ISR clear on read */
-	ret |= twl4030_i2c_write_u8(TWL4030_CHIP_KEYPAD,
-				    TWL4030_KEYPAD_KEYP_SIH_CTRL, 0x05);
-	return 0;
-}
-
-static void rx51_kp_fill(u8 k, u8 mods)
-{
-	/* check if some cursor key without meta fn key was pressed */
-	if (!(mods & 2) && (k == 18 || k == 31 || k == 33 || k == 34)) {
-		keybuf[keybuf_tail++] = '\e';
-		keybuf_tail %= KEYBUF_SIZE;
-		keybuf[keybuf_tail++] = '[';
-		keybuf_tail %= KEYBUF_SIZE;
-		if (k == 18) /* up */
-			keybuf[keybuf_tail++] = 'A';
-		else if (k == 31) /* left */
-			keybuf[keybuf_tail++] = 'D';
-		else if (k == 33) /* down */
-			keybuf[keybuf_tail++] = 'B';
-		else if (k == 34) /* right */
-			keybuf[keybuf_tail++] = 'C';
-		keybuf_tail %= KEYBUF_SIZE;
-		return;
-	}
-
-	if (mods & 2) { /* fn meta key was pressed */
-		k = keymap[k+64];
-	} else {
-		k = keymap[k];
-		if (mods & 1) { /* ctrl key was pressed */
-			if (k >= 'a' && k <= 'z')
-				k -= 'a' - 1;
-		}
-		if (mods & 4) { /* shift key was pressed */
-			if (k >= 'a' && k <= 'z')
-				k += 'A' - 'a';
-			else if (k == '.')
-				k = ':';
-			else if (k == ',')
-				k = ';';
-		}
-	}
-	keybuf[keybuf_tail++] = k;
-	keybuf_tail %= KEYBUF_SIZE;
-}
-
-/*
- * Routine: rx51_kp_tstc
- * Description: Test if key was pressed (from buffer).
- */
-int rx51_kp_tstc(struct stdio_dev *sdev)
-{
-	u8 c, r, dk, i;
-	u8 intr;
-	u8 mods;
-
-	/* localy lock twl4030 i2c bus */
-	if (test_and_set_bit(0, &twl_i2c_lock))
-		return 0;
-
-	/* twl4030 remembers up to 2 events */
-	for (i = 0; i < 2; i++) {
-
-		/* check interrupt register for events */
-		twl4030_i2c_read_u8(TWL4030_CHIP_KEYPAD,
-				    TWL4030_KEYPAD_KEYP_ISR1 + (2 * i), &intr);
-
-		/* no event */
-		if (!(intr&1))
-			continue;
-
-		/* read the key state */
-		twl4030_i2c_read(TWL4030_CHIP_KEYPAD,
-				 TWL4030_KEYPAD_FULL_CODE_7_0, keys, 8);
-
-		/* cut out modifier keys from the keystate */
-		mods = keys[4] >> 4;
-		keys[4] &= 0x0f;
-
-		for (c = 0; c < 8; c++) {
-
-			/* get newly pressed keys only */
-			dk = ((keys[c] ^ old_keys[c])&keys[c]);
-			old_keys[c] = keys[c];
-
-			/* fill the keybuf */
-			for (r = 0; r < 8; r++) {
-				if (dk&1)
-					rx51_kp_fill((c*8)+r, mods);
-				dk = dk >> 1;
-			}
-
-		}
-
-	}
-
-	/* localy unlock twl4030 i2c bus */
-	test_and_clear_bit(0, &twl_i2c_lock);
-
-	return (KEYBUF_SIZE + keybuf_tail - keybuf_head)%KEYBUF_SIZE;
-}
-
-/*
- * Routine: rx51_kp_getc
- * Description: Get last pressed key (from buffer).
- */
-int rx51_kp_getc(struct stdio_dev *sdev)
-{
-	keybuf_head %= KEYBUF_SIZE;
-	while (!rx51_kp_tstc(sdev))
-		WATCHDOG_RESET();
-	return keybuf[keybuf_head++];
-}
-
-static const struct mmc_config rx51_mmc_cfg = {
-	.host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
-	.f_min = 400000,
-	.f_max = 52000000,
-	.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
-	.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
-};
-
-static const struct omap_hsmmc_plat rx51_mmc[] = {
-	{ rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC1_BASE },
-	{ rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC2_BASE },
-};
-
-U_BOOT_DRVINFOS(rx51_mmc) = {
-	{ "omap_hsmmc", &rx51_mmc[0] },
-	{ "omap_hsmmc", &rx51_mmc[1] },
-};
-
-static const struct omap_i2c_plat rx51_i2c[] = {
-	{ I2C_BASE1, 100000, OMAP_I2C_REV_V1 },
-	{ I2C_BASE2, 100000, OMAP_I2C_REV_V1 },
-	{ I2C_BASE3, 100000, OMAP_I2C_REV_V1 },
-};
-
-U_BOOT_DRVINFOS(rx51_i2c) = {
-	{ "i2c_omap", &rx51_i2c[0] },
-	{ "i2c_omap", &rx51_i2c[1] },
-	{ "i2c_omap", &rx51_i2c[2] },
-};
diff --git a/board/nokia/rx51/tag_omap.h b/board/nokia/rx51/tag_omap.h
deleted file mode 100644
index b99d6b7de17f..000000000000
--- a/board/nokia/rx51/tag_omap.h
+++ /dev/null
@@ -1,294 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2011-2012
- * Pali Roh?r <pali@kernel.org>
- *
- * (C) Copyright 2011
- * marcel at mesa.nl, Mesa Consulting B.V.
- *
- * (C) Copyright 2004-2005
- * Nokia Corporation
- */
-
-
-/*
- *  Code copied from maemo kernel 2.6.28 file
- *  arch/arm/plat-omap/include/mach/board.h
- *
- *  Information structures for board-specific data
- *
- *  Copyright (C) 2004	Nokia Corporation
- *  Written by Juha Yrj?l? <juha.yrjola@nokia.com>
- */
-
-/* Different peripheral ids */
-#define OMAP_TAG_CLOCK		0x4f01
-#define OMAP_TAG_SERIAL_CONSOLE	0x4f03
-#define OMAP_TAG_USB		0x4f04
-#define OMAP_TAG_LCD		0x4f05
-#define OMAP_TAG_GPIO_SWITCH	0x4f06
-#define OMAP_TAG_UART		0x4f07
-#define OMAP_TAG_FBMEM		0x4f08
-#define OMAP_TAG_STI_CONSOLE	0x4f09
-#define OMAP_TAG_CAMERA_SENSOR	0x4f0a
-#define OMAP_TAG_PARTITION	0x4f0b
-#define OMAP_TAG_TEA5761	0x4f10
-#define OMAP_TAG_TMP105		0x4f11
-
-#define OMAP_TAG_BOOT_REASON	0x4f80
-#define OMAP_TAG_FLASH_PART_STR	0x4f81
-#define OMAP_TAG_VERSION_STR	0x4f82
-
-#define OMAP_TAG_NOKIA_BT	0x4e01
-#define OMAP_TAG_WLAN_CX3110X	0x4e02
-#define OMAP_TAG_CBUS		0x4e03
-#define OMAP_TAG_EM_ASIC_BB5	0x4e04
-
-
-struct omap_clock_config {
-	/* 0 for 12 MHz, 1 for 13 MHz and 2 for 19.2 MHz */
-	u8 system_clock_type;
-};
-
-struct omap_serial_console_config {
-	u8 console_uart;
-	u32 console_speed;
-};
-
-struct omap_sti_console_config {
-	unsigned enable:1;
-	u8 channel;
-};
-
-struct omap_usb_config {
-	/* Configure drivers according to the connectors on your board:
-	 *  - "A" connector (rectagular)
-	 *	... for host/OHCI use, set "register_host".
-	 *  - "B" connector (squarish) or "Mini-B"
-	 *	... for device/gadget use, set "register_dev".
-	 *  - "Mini-AB" connector (very similar to Mini-B)
-	 *	... for OTG use as device OR host, initialize "otg"
-	 */
-	unsigned	register_host:1;
-	unsigned	register_dev:1;
-	u8		otg;	/* port number, 1-based:  usb1 == 2 */
-
-	u8		hmc_mode;
-
-	/* implicitly true if otg:  host supports remote wakeup? */
-	u8		rwc;
-
-	/* signaling pins used to talk to transceiver on usbN:
-	 *  0 == usbN unused
-	 *  2 == usb0-only, using internal transceiver
-	 *  3 == 3 wire bidirectional
-	 *  4 == 4 wire bidirectional
-	 *  6 == 6 wire unidirectional (or TLL)
-	 */
-	u8		pins[3];
-};
-
-struct omap_lcd_config {
-	char panel_name[16];
-	char ctrl_name[16];
-	s16  nreset_gpio;
-	u8   data_lines;
-};
-
-struct omap_fbmem_config {
-	u32 start;
-	u32 size;
-};
-
-struct omap_gpio_switch_config {
-	char name[12];
-	u16 gpio;
-	u8 flags:4;
-	u8 type:4;
-	unsigned int key_code:24; /* Linux key code */
-};
-
-struct omap_uart_config {
-	/* Bit field of UARTs present; bit 0 --> UART1 */
-	unsigned int enabled_uarts;
-};
-
-struct omap_tea5761_config {
-	u16 enable_gpio;
-};
-
-struct omap_partition_config {
-	char name[16];
-	unsigned int size;
-	unsigned int offset;
-	/* same as in include/linux/mtd/partitions.h */
-	unsigned int mask_flags;
-};
-
-struct omap_flash_part_str_config {
-	char part_table[0];
-};
-
-struct omap_boot_reason_config {
-	char reason_str[12];
-};
-
-struct omap_version_config {
-	char component[12];
-	char version[12];
-};
-
-/*
- *  Code copied from maemo kernel 2.6.28 file
- *  arch/arm/plat-omap/include/mach/board-nokia.h
- *
- *  Information structures for Nokia-specific board config data
- *
- *  Copyright (C) 2005  Nokia Corporation
- */
-
-struct omap_bluetooth_config {
-	u8 chip_type;
-	u8 bt_wakeup_gpio;
-	u8 host_wakeup_gpio;
-	u8 reset_gpio;
-	u8 bt_uart;
-	u8 bd_addr[6];
-	u8 bt_sysclk;
-};
-
-struct omap_wlan_cx3110x_config {
-	u8 chip_type;
-	u8 reserverd;
-	s16 power_gpio;
-	s16 irq_gpio;
-	s16 spi_cs_gpio;
-};
-
-struct omap_cbus_config {
-	s16 clk_gpio;
-	s16 dat_gpio;
-	s16 sel_gpio;
-};
-
-struct omap_em_asic_bb5_config {
-	s16 retu_irq_gpio;
-	s16 tahvo_irq_gpio;
-};
-
-/*
- *  omap_tag handling
- *
- *  processing omap tag structures
- *
- *  Copyright (C) 2011  marcel at mesa.nl, Mesa Consulting B.V.
- *  Copyright (C) 2012  Pali Roh?r <pali@kernel.org>
- */
-
-/* TI OMAP specific information */
-#define ATAG_BOARD	0x414f4d50
-
-struct tag_omap_header {
-	u16 tag;
-	u16 size;
-};
-
-struct tag_omap {
-	struct tag_omap_header hdr;
-	union {
-		struct omap_clock_config clock;
-		struct omap_serial_console_config serial_console;
-		struct omap_sti_console_config sti_console;
-		struct omap_usb_config usb;
-		struct omap_lcd_config lcd;
-		struct omap_fbmem_config fbmem;
-		struct omap_gpio_switch_config gpio_switch;
-		struct omap_uart_config uart;
-		struct omap_tea5761_config tea5761;
-		struct omap_partition_config partition;
-		struct omap_flash_part_str_config flash_part_str;
-		struct omap_boot_reason_config boot_reason;
-		struct omap_version_config version;
-		struct omap_bluetooth_config bluetooth;
-		struct omap_wlan_cx3110x_config wlan_cx3110x;
-		struct omap_cbus_config cbus;
-		struct omap_em_asic_bb5_config em_asic_bb5;
-	} u;
-};
-
-#define tag_omap_next(t)	((struct tag_omap *)((u8 *)(t) + \
-				(t)->hdr.size + sizeof(struct tag_omap_header)))
-
-#define OMAP_TAG_HEADER_CONFIG(config, type) \
-	.hdr.tag = config, \
-	.hdr.size = sizeof(struct type)
-
-#define OMAP_TAG_UART_CONFIG(p1) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_UART, omap_uart_config), \
-		.u.uart.enabled_uarts = p1, \
-	}
-
-#define OMAP_TAG_SERIAL_CONSOLE_CONFIG(p1, p2) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_SERIAL_CONSOLE, \
-			omap_serial_console_config), \
-		.u.serial_console.console_uart = p1, \
-		.u.serial_console.console_speed = p2, \
-	}
-
-#define OMAP_TAG_LCD_CONFIG(p1, p2, p3, p4) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_LCD, omap_lcd_config), \
-		.u.lcd.panel_name = p1, \
-		.u.lcd.ctrl_name = p2, \
-		.u.lcd.nreset_gpio = p3, \
-		.u.lcd.data_lines = p4, \
-	}
-
-#define OMAP_TAG_GPIO_SWITCH_CONFIG(p1, p2, p3, p4, p5) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_GPIO_SWITCH, \
-			omap_gpio_switch_config), \
-		.u.gpio_switch.name = p1, \
-		.u.gpio_switch.gpio = p2, \
-		.u.gpio_switch.flags = p3, \
-		.u.gpio_switch.type = p4, \
-		.u.gpio_switch.key_code = p5, \
-	}
-
-#define OMAP_TAG_WLAN_CX3110X_CONFIG(p1, p2, p3, p4, p5) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_WLAN_CX3110X, \
-			omap_wlan_cx3110x_config), \
-		.u.wlan_cx3110x.chip_type = p1, \
-		.u.wlan_cx3110x.reserverd = p2, \
-		.u.wlan_cx3110x.power_gpio = p3, \
-		.u.wlan_cx3110x.irq_gpio = p4, \
-		.u.wlan_cx3110x.spi_cs_gpio = p5, \
-	}
-
-#define OMAP_TAG_PARTITION_CONFIG(p1, p2, p3, p4) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_PARTITION, \
-			omap_partition_config), \
-		.u.partition.name = p1, \
-		.u.partition.size = p2, \
-		.u.partition.offset = p3, \
-		.u.partition.mask_flags = p4, \
-	}
-
-#define OMAP_TAG_BOOT_REASON_CONFIG(p1) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_BOOT_REASON, \
-			omap_boot_reason_config), \
-		.u.boot_reason.reason_str = p1, \
-	}
-
-#define OMAP_TAG_VERSION_STR_CONFIG(p1, p2) \
-	{ \
-		OMAP_TAG_HEADER_CONFIG(OMAP_TAG_VERSION_STR, \
-			omap_version_config), \
-		.u.version.component = p1, \
-		.u.version.version = p2, \
-	}
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
deleted file mode 100644
index f79613260f3e..000000000000
--- a/configs/nokia_rx51_defconfig
+++ /dev/null
@@ -1,69 +0,0 @@
-CONFIG_ARM=y
-# CONFIG_SYS_THUMB_BUILD is not set
-CONFIG_ARCH_OMAP2PLUS=y
-CONFIG_SYS_TEXT_BASE=0x80008000
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_TARGET_NOKIA_RX51=y
-CONFIG_OPTIMIZE_INLINING=y
-# CONFIG_SYS_MALLOC_F is not set
-# CONFIG_FIT is not set
-CONFIG_BOOTDELAY=30
-CONFIG_AUTOBOOT_KEYED=y
-CONFIG_AUTOBOOT_MENU_SHOW=y
-CONFIG_USE_PREBOOT=y
-CONFIG_PREBOOT="run preboot"
-CONFIG_CONSOLE_MUX=y
-# CONFIG_SYS_DEVICE_NULLDEV is not set
-CONFIG_HUSH_PARSER=y
-CONFIG_SYS_PROMPT="Nokia RX-51 # "
-# CONFIG_CMD_BDI is not set
-# 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_CMD_BOOTMENU=y
-# CONFIG_CMD_ELF is not set
-# CONFIG_CMD_IMI 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_SAVEENV is not set
-# CONFIG_CMD_ENV_EXISTS is not set
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_MTD=y
-CONFIG_CMD_ONENAND=y
-# CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_SLEEP is not set
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
-CONFIG_MTDIDS_DEFAULT="onenand0=onenand"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=onenand:128k(bootloader)ro,384k(config),256k(log),2m(kernel),2m(initfs),-(rootfs)"
-CONFIG_ENV_OVERWRITE=y
-CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-# CONFIG_NET is not set
-CONFIG_DM=y
-# CONFIG_DM_WARN is not set
-# CONFIG_DM_DEVICE_REMOVE is not set
-# CONFIG_DM_SEQ_ALIAS is not set
-# CONFIG_BLOCK_CACHE is not set
-CONFIG_DM_I2C=y
-# CONFIG_MMC_HW_PARTITIONING is not set
-# CONFIG_MMC_VERBOSE is not set
-CONFIG_MMC_OMAP_HS=y
-CONFIG_MTD=y
-CONFIG_CONS_INDEX=3
-CONFIG_SYS_NS16550=y
-CONFIG_SPI=y
-CONFIG_USB=y
-CONFIG_USB_MUSB_UDC=y
-CONFIG_USB_OMAP3=y
-CONFIG_CFB_CONSOLE=y
-CONFIG_CFB_CONSOLE_ANSI=y
-# CONFIG_VGA_AS_SINGLE_DEVICE is not set
-CONFIG_SPLASH_SCREEN=y
-# CONFIG_GZIP is not set
diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
deleted file mode 100644
index 84d1912ddd2b..000000000000
--- a/doc/README.nokia_rx51
+++ /dev/null
@@ -1,94 +0,0 @@
-Board: Nokia RX-51 aka N900
-
-This board definition results in a u-boot.bin which can be chainloaded
-from NOLO in qemu or on a real N900. It does very little hardware config
-because NOLO has already configured the board. Only needed is enabling
-internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
-
-NOLO is expecting a kernel image and will treat any image it finds in
-onenand as such. This u-boot is intended to be flashed to the N900 like
-a kernel. In order to transparently boot the original kernel, it will be
-appended to u-boot.bin at 0x40000. NOLO will load the entire image into
-(random) memory and execute u-boot, which saves hw revision, boot reason
-and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
-uImage or boot.scr from a fat, ext2/ext3 or ext4 filesystem in external
-SD card or internal eMMC memory. If this fails or keyboard is closed then
-the appended kernel image will be booted using some generated and some
-stored ATAGs (see boot order).
-
-For generating combined image of u-boot and kernel there is a simple script
-called u-boot-gen-combined. It is available in following repository:
-
-  https://github.com/pali/u-boot-maemo
-
-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 escape codes and the N900 HW keyboard input.
-
-When U-Boot is starting it enable IBE bit in Auxiliary Control Register,
-which is needed for Thumb-2 ISA support. It is workaround for errata 430973.
-
-Default boot order:
-
- * 0. if keyboard is closed boot automatically attached kernel image
- * 1. try boot from external SD card
- * 2. try boot from internal eMMC memory
- * 3. try boot from attached kernel image
-
-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 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
-
-
-Available additional commands/variables:
-
- * run sdboot - Boot from external SD card (see boot order)
- * run emmcboot - Boot from internal eMMC memory (see boot order)
- * run attachboot - Boot attached kernel image (attached to U-Boot binary)
-
- * run scriptload - Load boot script ${mmcscriptfile}
- * run scriptboot - Run loaded boot script
- * run kernload - Load kernel image ${mmckernfile}
- * run initrdload - Load initrd image ${mmcinitrdfile}
- * run kernboot - Boot loaded kernel image
- * run kerninitrdboot - Boot loaded kernel image with loaded initrd image
-
- * 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}
-
-Additional variables for loading files from mmc:
-
- * mmc ${mmcnum} (0 - external, 1 - internal)
- * partition number ${mmcpart} (1 - 4)
- * parition type ${mmctype} (fat, ext2, ext4)
-
-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.
-
-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 add following lines into file configs/nokia_rx51_defconfig
-
- CONFIG_CMD_UBI=y
- CONFIG_CMD_UBIFS=y
- CONFIG_MTD_UBI_FASTMAP=y
- CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
deleted file mode 100644
index 23368de624e1..000000000000
--- a/include/configs/nokia_rx51.h
+++ /dev/null
@@ -1,249 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2011-2012
- * Pali Roh?r <pali@kernel.org>
- *
- * (C) Copyright 2010
- * Alistair Buxton <a.j.buxton@gmail.com>
- *
- * Derived from Beagle Board code:
- * (C) Copyright 2006-2008
- * Texas Instruments.
- * Richard Woodruff <r-woodruff2@ti.com>
- * Syed Mohammed Khasim <x0khasim@ti.com>
- *
- * Configuration settings for the Nokia RX-51 aka N900.
- */
-
-#ifndef __CONFIG_H
-#define __CONFIG_H
-
-/*
- * High Level Configuration Options
- */
-#define CONFIG_SYS_L2CACHE_OFF		/* pretend there is no L2 CACHE */
-
-#define CONFIG_MACH_TYPE		MACH_TYPE_NOKIA_RX51
-
-#include <asm/arch/cpu.h>		/* get chip and board defs */
-#include <asm/arch/omap.h>
-#include <asm/arch/mem.h>
-#include <linux/stringify.h>
-
-/* Clock Defines */
-#define V_OSCK			26000000	/* Clock output from T2 */
-#define V_SCLK			(V_OSCK >> 1)
-
-#define CONFIG_SKIP_LOWLEVEL_INIT		/* X-Loader set everything up */
-
-#define CONFIG_CMDLINE_TAG	/* enable passing kernel command line string */
-#define CONFIG_INITRD_TAG			/* enable passing initrd */
-#define CONFIG_REVISION_TAG			/* enable passing revision tag*/
-#define CONFIG_SETUP_MEMORY_TAGS		/* enable memory tag */
-
-/*
- * Size of malloc() pool
- */
-#define CONFIG_UBI_SIZE			(512 << 10)
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + CONFIG_UBI_SIZE + \
-					(128 << 10))
-
-/*
- * Hardware drivers
- */
-
-/*
- * NS16550 Configuration
- */
-#define V_NS16550_CLK		48000000		/* 48MHz (APLL96/2) */
-
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE	(-4)
-#define CONFIG_SYS_NS16550_CLK		V_NS16550_CLK
-
-/*
- * select serial console configuration
- */
-#define CONFIG_SYS_NS16550_COM3		OMAP34XX_UART3
-
-#define CONFIG_SYS_BAUDRATE_TABLE { 4800, 9600, 19200, 38400, 57600, 115200 }
-
-/* USB device configuration */
-#define CONFIG_USB_DEVICE
-#define CONFIG_USB_TTY
-#define CONFIG_USBD_VENDORID		0x0421
-#define CONFIG_USBD_PRODUCTID_CDCACM	0x01c8
-#define CONFIG_USBD_PRODUCTID_GSERIAL	0x01c8
-#define CONFIG_USBD_MANUFACTURER	"Nokia"
-#define CONFIG_USBD_PRODUCT_NAME	"N900 (U-Boot)"
-
-#define GPIO_SLIDE			71
-
-/*
- * Board ONENAND Info.
- */
-
-#define CONFIG_SYS_ONENAND_BASE		ONENAND_MAP
-
-/* Watchdog support */
-#define CONFIG_HW_WATCHDOG
-
-/*
- * Framebuffer
- */
-/* Video console */
-#define CONFIG_VIDEO_LOGO
-#define VIDEO_FB_16BPP_PIXEL_SWAP
-#define VIDEO_FB_16BPP_WORD_SWAP
-
-/* functions for cfb_console */
-#define VIDEO_KBD_INIT_FCT		rx51_kp_init()
-#define VIDEO_TSTC_FCT			rx51_kp_tstc
-#define VIDEO_GETC_FCT			rx51_kp_getc
-#ifndef __ASSEMBLY__
-struct stdio_dev;
-int rx51_kp_init(void);
-int rx51_kp_tstc(struct stdio_dev *sdev);
-int rx51_kp_getc(struct stdio_dev *sdev);
-#endif
-
-/* Environment information */
-#define CONFIG_EXTRA_ENV_SETTINGS \
-	"usbtty=cdc_acm\0" \
-	"stdin=usbtty,serial,vga\0" \
-	"stdout=usbtty,serial,vga\0" \
-	"stderr=usbtty,serial,vga\0" \
-	"slide=gpio input " __stringify(GPIO_SLIDE) "\0" \
-	"switchmmc=mmc dev ${mmcnum}\0" \
-	"kernaddr=0x82008000\0" \
-	"initrdaddr=0x84008000\0" \
-	"scriptaddr=0x86008000\0" \
-	"fileload=${mmctype}load mmc ${mmcnum}:${mmcpart} " \
-		"${loadaddr} ${mmcfile}\0" \
-	"kernload=setenv loadaddr ${kernaddr};" \
-		"setenv mmcfile ${mmckernfile};" \
-		"run fileload\0" \
-	"initrdload=setenv loadaddr ${initrdaddr};" \
-		"setenv mmcfile ${mmcinitrdfile};" \
-		"run fileload\0" \
-	"scriptload=setenv loadaddr ${scriptaddr};" \
-		"setenv mmcfile ${mmcscriptfile};" \
-		"run fileload\0" \
-	"scriptboot=echo Running ${mmcscriptfile} from mmc " \
-		"${mmcnum}:${mmcpart} ...; source ${scriptaddr}\0" \
-	"kernboot=echo Booting ${mmckernfile} from mmc " \
-		"${mmcnum}:${mmcpart} ...; bootm ${kernaddr}\0" \
-	"kerninitrdboot=echo Booting ${mmckernfile} ${mmcinitrdfile} from mmc "\
-		"${mmcnum}:${mmcpart} ...; bootm ${kernaddr} ${initrdaddr}\0" \
-	"attachboot=echo Booting attached kernel image ...;" \
-		"setenv setup_omap_atag 1;" \
-		"bootm ${attkernaddr};" \
-		"setenv setup_omap_atag\0" \
-	"trymmcscriptboot=if run switchmmc; then " \
-			"if run scriptload; then " \
-				"run scriptboot;" \
-			"fi;" \
-		"fi\0" \
-	"trymmckernboot=if run switchmmc; then " \
-			"if run kernload; then " \
-				"run kernboot;" \
-			"fi;" \
-		"fi\0" \
-	"trymmckerninitrdboot=if run switchmmc; then " \
-			"if run initrdload; then " \
-				"if run kernload; then " \
-					"run kerninitrdboot;" \
-				"fi;" \
-			"fi; " \
-		"fi\0" \
-	"trymmcpartboot=setenv mmcscriptfile boot.scr; run trymmcscriptboot;" \
-		"setenv mmckernfile uImage; run trymmckernboot\0" \
-	"trymmcallpartboot=setenv mmcpart 1; run trymmcpartboot;" \
-		"setenv mmcpart 2; run trymmcpartboot;" \
-		"setenv mmcpart 3; run trymmcpartboot;" \
-		"setenv mmcpart 4; run trymmcpartboot\0" \
-	"trymmcboot=if run switchmmc; then " \
-			"setenv mmctype fat;" \
-			"run trymmcallpartboot;" \
-			"setenv mmctype ext4;" \
-			"run trymmcallpartboot;" \
-		"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 mmctype fat;" \
-			"if run scriptload; then run scriptboot; else " \
-				"setenv mmctype ext4;" \
-				"if run scriptload; then run scriptboot; fi;" \
-			"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" \
-	"bootmenu_2=External SD card=run sdboot\0" \
-	"bootmenu_3=U-Boot boot order=boot\0" \
-	"bootmenu_delay=30\0" \
-	""
-
-#define CONFIG_POSTBOOTMENU \
-	"echo;" \
-	"echo Extra commands:;" \
-	"echo run sdboot - Boot from SD card slot.;" \
-	"echo run emmcboot - Boot internal eMMC memory.;" \
-	"echo run attachboot - Boot attached kernel image.;" \
-	"echo"
-
-#define CONFIG_BOOTCOMMAND \
-	"run sdboot;" \
-	"run emmcboot;" \
-	"run attachboot;" \
-	"echo"
-
-/* default load address */
-#define CONFIG_SYS_LOAD_ADDR		(OMAP34XX_SDRC_CS0)
-
-/*
- * OMAP3 has 12 GP timers, they can be driven by the system clock
- * (12/13/16.8/19.2/38.4MHz) or by 32KHz clock. We use 13MHz (V_SCLK).
- * This rate is divided by a local divisor.
- */
-#define CONFIG_SYS_TIMERBASE		(OMAP34XX_GPT2)
-#define CONFIG_SYS_PTV			2	/* Divisor: 2^(PTV+1) => 8 */
-
-/*
- * Physical Memory Map
- */
-#define PHYS_SDRAM_1			OMAP34XX_SDRC_CS0
-
-/*
- * FLASH and environment organization
- */
-
-#define CONFIG_SYS_SDRAM_BASE		PHYS_SDRAM_1
-#define CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
-#define CONFIG_SYS_INIT_RAM_SIZE	0x800
-#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
-			CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE)
-
-/*
- * Attached kernel image
- */
-
-#define SDRAM_SIZE			0x10000000	/* 256 MB */
-#define SDRAM_END			(CONFIG_SYS_SDRAM_BASE + SDRAM_SIZE)
-
-#define IMAGE_MAXSIZE			0x1FF800	/* 2 MB - 2 kB */
-#define KERNEL_OFFSET			0x40000		/* 256 kB */
-#define KERNEL_MAXSIZE			(IMAGE_MAXSIZE-KERNEL_OFFSET)
-#define KERNEL_ADDRESS			(SDRAM_END-KERNEL_MAXSIZE)
-
-/* Reserve protected RAM for attached kernel */
-#define CONFIG_PRAM			((KERNEL_MAXSIZE >> 10)+1)
-
-#endif /* __CONFIG_H */
diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh
deleted file mode 100755
index ee45e8d6dd58..000000000000
--- a/test/nokia_rx51_test.sh
+++ /dev/null
@@ -1,296 +0,0 @@
-#!/bin/bash -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 U-Boot serial console testing
-cat > bootmenu_uboot << EOF
-setenv bootmenu_0 'Serial console test=echo; echo "Testing serial console"; echo; echo "Successfully booted"; echo; poweroff';
-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_uboot -d bootmenu_uboot bootmenu_uboot.scr
-
-# 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_emmc -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_nand -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 U-Boot serial console testing
-truncate -s 50MiB emmc_uboot.img
-mformat -m 0xf8 -F -h 4 -s 16 -c 1 -t $((50*1024*1024/(4*16*512))) :: -i emmc_uboot.img
-mcopy bootmenu_uboot.scr ::/bootmenu.scr -i emmc_uboot.img
-
-# 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 U-Boot serial console testing
-rm -f mtd_uboot.img
-./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -m rx51 -o mtd_uboot.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 U-Boot prints testing string to serial console and poweroff
-rm -f qemu_uboot.log
-./qemu-system-arm -M n900 -mtdblock mtd_uboot.img -sd emmc_uboot.img -serial /dev/stdout -display none > qemu_uboot.log &
-qemu_pid=$!
-tail -F qemu_uboot.log &
-tail_pid=$!
-sleep 300 &
-sleep_pid=$!
-wait -n $sleep_pid $qemu_pid || true
-kill -9 $tail_pid $sleep_pid $qemu_pid 2>/dev/null || true
-wait || true
-
-# 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 &
-sleep_pid=$!
-wait -n $sleep_pid $qemu_pid || true
-kill -9 $tail_pid $sleep_pid $qemu_pid 2>/dev/null || true
-wait || 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 &
-sleep_pid=$!
-wait -n $sleep_pid $qemu_pid || true
-kill -9 $tail_pid $sleep_pid $qemu_pid 2>/dev/null || true
-wait || 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 &
-sleep_pid=$!
-wait -n $sleep_pid $qemu_pid || true
-kill -9 $tail_pid $sleep_pid $qemu_pid 2>/dev/null || true
-wait || true
-
-echo
-echo "============================="
-echo "========== Results =========="
-echo "============================="
-echo
-
-if grep -q 'Successfully booted' qemu_uboot.log; then echo "U-Boot serial console is working"; else echo "U-Boot serial console test failed"; fi
-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_uboot.log && 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.17.1

[PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> This board has not been converted to CONFIG_DM_USB by the deadline.
> Remove it.

I'm very disappointed that you want to remove Nokia N900 from U-Boot.

I was waiting waiting half of year because other developers did not
react to issues which were introduced and neither to patches which I
sent (+ trying to remind open issues). And also I was waiting another
half of year until other N900 related patches were merged. So the whole
slowdown was not caused by me, why it is taking so long.

Now there is still one N900 DM related patch waiting for review. I'm
converting code step by step.

So the ball is not on my side.

> Cc: Pali Roh?r <pali@kernel.org>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> I assume you'll be trying to fix this so I've not removed all of the
> test related scripts.
> ---
>  .azure-pipelines.yml              |  13 -
>  .gitlab-ci.yml                    |   7 -
>  arch/arm/mach-omap2/omap3/Kconfig |   4 -
>  board/nokia/rx51/Kconfig          |  12 -
>  board/nokia/rx51/MAINTAINERS      |   8 -
>  board/nokia/rx51/Makefile         |   7 -
>  board/nokia/rx51/lowlevel_init.S  | 196 --------
>  board/nokia/rx51/rx51.c           | 724 ------------------------------
>  board/nokia/rx51/tag_omap.h       | 294 ------------
>  configs/nokia_rx51_defconfig      |  69 ---
>  doc/README.nokia_rx51             |  94 ----
>  include/configs/nokia_rx51.h      | 249 ----------
>  test/nokia_rx51_test.sh           | 296 ------------
>  13 files changed, 1973 deletions(-)
>  delete mode 100644 board/nokia/rx51/Kconfig
>  delete mode 100644 board/nokia/rx51/MAINTAINERS
>  delete mode 100644 board/nokia/rx51/Makefile
>  delete mode 100644 board/nokia/rx51/lowlevel_init.S
>  delete mode 100644 board/nokia/rx51/rx51.c
>  delete mode 100644 board/nokia/rx51/tag_omap.h
>  delete mode 100644 configs/nokia_rx51_defconfig
>  delete mode 100644 doc/README.nokia_rx51
>  delete mode 100644 include/configs/nokia_rx51.h
>  delete mode 100755 test/nokia_rx51_test.sh

[PATCH] arm: Remove nokia_rx51 board

[Oleh Kravchenko]

Hello Pali,
Is there some wiki page on how to flash u-boot and Linux to N900 (JTAG,
UART, etc.)?

I have this device and would like to play with that.


19.05.21 16:27, Pali Roh?r ????:
> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>> This board has not been converted to CONFIG_DM_USB by the deadline.
>> Remove it.
> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>
> I was waiting waiting half of year because other developers did not
> react to issues which were introduced and neither to patches which I
> sent (+ trying to remind open issues). And also I was waiting another
> half of year until other N900 related patches were merged. So the whole
> slowdown was not caused by me, why it is taking so long.
>
> Now there is still one N900 DM related patch waiting for review. I'm
> converting code step by step.
>
> So the ball is not on my side.
>
>> Cc: Pali Roh?r <pali@kernel.org>
>> Signed-off-by: Tom Rini <trini@konsulko.com>
>> ---
>> I assume you'll be trying to fix this so I've not removed all of the
>> test related scripts.
>> ---
>>  .azure-pipelines.yml              |  13 -
>>  .gitlab-ci.yml                    |   7 -
>>  arch/arm/mach-omap2/omap3/Kconfig |   4 -
>>  board/nokia/rx51/Kconfig          |  12 -
>>  board/nokia/rx51/MAINTAINERS      |   8 -
>>  board/nokia/rx51/Makefile         |   7 -
>>  board/nokia/rx51/lowlevel_init.S  | 196 --------
>>  board/nokia/rx51/rx51.c           | 724 ------------------------------
>>  board/nokia/rx51/tag_omap.h       | 294 ------------
>>  configs/nokia_rx51_defconfig      |  69 ---
>>  doc/README.nokia_rx51             |  94 ----
>>  include/configs/nokia_rx51.h      | 249 ----------
>>  test/nokia_rx51_test.sh           | 296 ------------
>>  13 files changed, 1973 deletions(-)
>>  delete mode 100644 board/nokia/rx51/Kconfig
>>  delete mode 100644 board/nokia/rx51/MAINTAINERS
>>  delete mode 100644 board/nokia/rx51/Makefile
>>  delete mode 100644 board/nokia/rx51/lowlevel_init.S
>>  delete mode 100644 board/nokia/rx51/rx51.c
>>  delete mode 100644 board/nokia/rx51/tag_omap.h
>>  delete mode 100644 configs/nokia_rx51_defconfig
>>  delete mode 100644 doc/README.nokia_rx51
>>  delete mode 100644 include/configs/nokia_rx51.h
>>  delete mode 100755 test/nokia_rx51_test.sh

[PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Wednesday 19 May 2021 17:27:32 Oleh Kravchenko wrote:
> Hello Pali,
> Is there some wiki page on how to flash u-boot and Linux to N900 (JTAG,
> UART, etc.)?

Flashing UART or JTAG could be possible with proprietary Nokia flasher.
But there are just very few people with UART access to Nokia N900 so I'm
not sure if somebody has some guideline for UART and flashing.

What is working fine and is heavily tested is booting or flashing via
USB. Some information is in doc/README.nokia_rx51 file, other in 0xFFFF
manpage and I was planning to send a patch with doc update...


diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 84d1912ddd2b..9bead311fdf8 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -21,6 +21,36 @@ called u-boot-gen-combined. It is available in following repository:
 
   https://github.com/pali/u-boot-maemo
 
+Flashed image must start with 2 kB "NOLO!img" header which contains size of
+the image. Header consist of bytes "NOLO!img\x02\x00\x00\x00\x00\x00\x00\x00"
+followed by 4 byte little endian size of the image and rest of the 2 kB header
+are just zero bytes.
+
+Nokia proprietary flasher and also open source 0xFFFF flasher automatically
+prepend required "NOLO!img" header and both applications expect that image
+does not contain "NOLO!img" header. Adding "NOLO!img" header is required
+only in case using "nandwrite" tool for flashing.
+
+Open source 0xFFFF flasher is available in following repository:
+
+  https://github.com/pali/0xFFFF
+
+It is possible to load u-boot.bin via USB to N900 RAM and boot it without
+need to flashing it. Via 0xFFFF running at host PC it is done:
+
+  0xFFFF -m u-boot.bin -l -b
+
+0xFFFF support also flashing kernel image either via USB or directly on
+N900 device. Flashing u-boot/kernel/combined image is done as:
+
+  0xFFFF -m combined.bin -f
+
+Via 0xFFFF is possible to generate also standard flashable image in Nokia
+FIASCO format which contains metadata information like device identification
+(RX-51) and version string (v2021.04):
+
+  0xFFFF -m RX-51:v2021.04:kernel:u-boot.bin -g u-boot.fiasco
+
 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



> I have this device and would like to play with that.

[PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Roh?r wrote:

> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > This board has not been converted to CONFIG_DM_USB by the deadline.
> > Remove it.
> 
> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> 
> I was waiting waiting half of year because other developers did not
> react to issues which were introduced and neither to patches which I
> sent (+ trying to remind open issues). And also I was waiting another
> half of year until other N900 related patches were merged. So the whole
> slowdown was not caused by me, why it is taking so long.
> 
> Now there is still one N900 DM related patch waiting for review. I'm
> converting code step by step.
> 
> So the ball is not on my side.

So, what patch(es) need to be applied to get DM_USB enabled?  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/20210519/e9410c97/attachment.sig>

[PATCH] arm: Remove nokia_rx51 board

[Pavel Machek]

On Tue 2021-05-18 21:26:40, Tom Rini wrote:
> This board has not been converted to CONFIG_DM_USB by the deadline.
> Remove it.

Given that the board is in a active use and that Pali is actively
working on it... That does not seem like good idea or sensible thing
to do.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek
-------------- 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/20210519/d9a1411f/attachment.sig>

[PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

On Wed, May 19, 2021 at 09:06:53PM +0200, Pavel Machek wrote:
> On Tue 2021-05-18 21:26:40, Tom Rini wrote:
> > This board has not been converted to CONFIG_DM_USB by the deadline.
> > Remove it.
> 
> Given that the board is in a active use and that Pali is actively
> working on it... That does not seem like good idea or sensible thing
> to do.

That's why I posted this patch now, while I'm working on the rest of the
to be removed boards.  We're about to be 2 years past the conversion
deadline which has been part of every build for at least a year prior to
that.  One way or another, whatever is blocking progress needs to get
resolved.

-- 
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/20210519/89877be3/attachment.sig>

Re: [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> 
> > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > Remove it.
> > 
> > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > 
> > I was waiting waiting half of year because other developers did not
> > react to issues which were introduced and neither to patches which I
> > sent (+ trying to remind open issues). And also I was waiting another
> > half of year until other N900 related patches were merged. So the whole
> > slowdown was not caused by me, why it is taking so long.
> > 
> > Now there is still one N900 DM related patch waiting for review. I'm
> > converting code step by step.
> > 
> > So the ball is not on my side.
> 
> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.

I don't see any open patches from you that look related to enabling
DM_USB on the platform.  If you want to disable USB on the platform for
now instead, that's fine too.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > 
> > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > Remove it.
> > > 
> > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > 
> > > I was waiting waiting half of year because other developers did not
> > > react to issues which were introduced and neither to patches which I
> > > sent (+ trying to remind open issues). And also I was waiting another
> > > half of year until other N900 related patches were merged. So the whole
> > > slowdown was not caused by me, why it is taking so long.
> > > 
> > > Now there is still one N900 DM related patch waiting for review. I'm
> > > converting code step by step.
> > > 
> > > So the ball is not on my side.
> > 
> > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> 
> I don't see any open patches from you that look related to enabling
> DM_USB on the platform.  If you want to disable USB on the platform for
> now instead, that's fine too.

I wanted to look at next DM step -- USB -- after current DM step
watchdog is finished. But patch for watchdog is still waiting for
review:

http://patchwork.ozlabs.org/project/uboot/patch/20210309201915.16586-1-pali@kernel.org/

Due to big chance of diff conflicts between these board patches, I do
not want to have more than one part of code in "in progress" state.

Re: [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Fri, May 21, 2021 at 11:36:45PM +0200, Pali Rohár wrote:
> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > 
> > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > Remove it.
> > > > 
> > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > 
> > > > I was waiting waiting half of year because other developers did not
> > > > react to issues which were introduced and neither to patches which I
> > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > half of year until other N900 related patches were merged. So the whole
> > > > slowdown was not caused by me, why it is taking so long.
> > > > 
> > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > converting code step by step.
> > > > 
> > > > So the ball is not on my side.
> > > 
> > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > 
> > I don't see any open patches from you that look related to enabling
> > DM_USB on the platform.  If you want to disable USB on the platform for
> > now instead, that's fine too.
> 
> I wanted to look at next DM step -- USB -- after current DM step
> watchdog is finished. But patch for watchdog is still waiting for
> review:
> 
> http://patchwork.ozlabs.org/project/uboot/patch/20210309201915.16586-1-pali@kernel.org/
> 
> Due to big chance of diff conflicts between these board patches, I do
> not want to have more than one part of code in "in progress" state.

The watchdog patch is blocked on LTO, which I will grab for this current
release, but also has a deadline of v2019.10 and USB is v2019.07, so
that's backwards.

Please work on a DM_USB / OF_CONTROL (as USB requires this) patch on top
of the WDT one which looks fine and hasn't been merged due to the LTO
series needing to come in first.  I'll drop this part from my full
DM_USB series posting.  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

Hi,

On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>
>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>> Remove it.
>>>>
>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>
>>>> I was waiting waiting half of year because other developers did not
>>>> react to issues which were introduced and neither to patches which I
>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>> half of year until other N900 related patches were merged. So the whole
>>>> slowdown was not caused by me, why it is taking so long.
>>>>
>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>> converting code step by step.
>>>>
>>>> So the ball is not on my side.
>>>
>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>
>> I don't see any open patches from you that look related to enabling
>> DM_USB on the platform.  If you want to disable USB on the platform for
>> now instead, that's fine too.
> 

I tried to migrate the latest master to DM_USB, but unfortunately the 
results are pretty much sad - adding OF_CONTROL (which is a prerequisite 
to have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k 
to the size of the u-boot binary, so it becomes 370284 bytes. Given that 
we have less than 256k of storage space for the u-boot, the produced 
binary cannot be used on n900 the same way current (no DM_USB) binary is 
used.

As I see it, there are not much options left - u-boot on N900 is not 
SPL, so we can't use OF_PLATDATA, which in turn always links libfdt.
Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB 
requires the board to be converted to DT and this is way bigger change.

Please advice on how to proceed.

> I wanted to look at next DM step -- USB -- after current DM step
> watchdog is finished. But patch for watchdog is still waiting for
> review:
> 
> http://patchwork.ozlabs.org/project/uboot/patch/20210309201915.16586-1-pali@kernel.org/
> 
> Due to big chance of diff conflicts between these board patches, I do
> not want to have more than one part of code in "in progress" state.

Regards,
Ivo

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > 
> > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > Remove it.
> > > > > 
> > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > 
> > > > > I was waiting waiting half of year because other developers did not
> > > > > react to issues which were introduced and neither to patches which I
> > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > half of year until other N900 related patches were merged. So the whole
> > > > > slowdown was not caused by me, why it is taking so long.
> > > > > 
> > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > converting code step by step.
> > > > > 
> > > > > So the ball is not on my side.
> > > > 
> > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > 
> > > I don't see any open patches from you that look related to enabling
> > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > now instead, that's fine too.
> > 
> 
> I tried to migrate the latest master to DM_USB, but unfortunately the
> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> less than 256k of storage space for the u-boot, the produced binary cannot
> be used on n900 the same way current (no DM_USB) binary is used.
> 
> As I see it, there are not much options left - u-boot on N900 is not SPL, so
> we can't use OF_PLATDATA, which in turn always links libfdt.
> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> the board to be converted to DT and this is way bigger change.
> 
> Please advice on how to proceed.

Please post your WIP patches, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

Hi,

On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>
>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>> Remove it.
>>>>>>
>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>
>>>>>> I was waiting waiting half of year because other developers did not
>>>>>> react to issues which were introduced and neither to patches which I
>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>
>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>> converting code step by step.
>>>>>>
>>>>>> So the ball is not on my side.
>>>>>
>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>
>>>> I don't see any open patches from you that look related to enabling
>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>> now instead, that's fine too.
>>>
>>
>> I tried to migrate the latest master to DM_USB, but unfortunately the
>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>> less than 256k of storage space for the u-boot, the produced binary cannot
>> be used on n900 the same way current (no DM_USB) binary is used.
>>
>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>> we can't use OF_PLATDATA, which in turn always links libfdt.
>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>> the board to be converted to DT and this is way bigger change.
>>
>> Please advice on how to proceed.
> 
> Please post your WIP patches, thanks.
> 

Sorry, I am not sure I understand what patches you want me to post:

WDT patch has already been sent couple of months ago - 
https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
Do you want it to be rebased and resend?

DM_USB, I just started writing one and I immediately hit the OF_CONTROL 
requirement. Enabling OF_CONTROL requires a full blown migration to DT, 
which is a huge task and not really equal to "Please update the board to 
use CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:

/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
DWARF error: could not find abbrev number 3998
/tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
<artificial>:(.text+0x5672): undefined reference to 
`ofnode_read_u32_default'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
<artificial>:(.text+0x568c): undefined reference to 
`ofnode_read_u32_default'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
/tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
<artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
<artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
<artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
/tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8): 
undefined reference to `dm_scan_fdt_dev'
/usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: 
/tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8): 
undefined reference to `dm_scan_fdt_dev'

Fixing those requires enabling of OF_CONTROL and this in turn means the 
board must be migrated to DT, unless I am missing something. That's why 
my "please advice..." stance.

Thanks,
Ivo

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Adam Ford]

On Wed, Jun 16, 2021 at 6:26 AM Ivaylo Dimitrov
<ivo.g.dimitrov.75@gmail.com> wrote:
>
> Hi,
>
> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> >> Hi,
> >>
> >> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> >>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> >>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> >>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> >>>>>
> >>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> >>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
> >>>>>>> Remove it.
> >>>>>>
> >>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> >>>>>>
> >>>>>> I was waiting waiting half of year because other developers did not
> >>>>>> react to issues which were introduced and neither to patches which I
> >>>>>> sent (+ trying to remind open issues). And also I was waiting another
> >>>>>> half of year until other N900 related patches were merged. So the whole
> >>>>>> slowdown was not caused by me, why it is taking so long.
> >>>>>>
> >>>>>> Now there is still one N900 DM related patch waiting for review. I'm
> >>>>>> converting code step by step.
> >>>>>>
> >>>>>> So the ball is not on my side.
> >>>>>
> >>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> >>>>
> >>>> I don't see any open patches from you that look related to enabling
> >>>> DM_USB on the platform.  If you want to disable USB on the platform for
> >>>> now instead, that's fine too.
> >>>
> >>
> >> I tried to migrate the latest master to DM_USB, but unfortunately the
> >> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> >> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> >> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> >> less than 256k of storage space for the u-boot, the produced binary cannot
> >> be used on n900 the same way current (no DM_USB) binary is used.

Have you experimented with enabling LTO?  I was successful in enabling
LTO on an OMAP3530 and a DM3730 which really helped reduce the code
size and I didn't notice any obvious regressions.

adam
> >>
> >> As I see it, there are not much options left - u-boot on N900 is not SPL, so
> >> we can't use OF_PLATDATA, which in turn always links libfdt.
> >> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> >> the board to be converted to DT and this is way bigger change.
> >>
> >> Please advice on how to proceed.
> >
> > Please post your WIP patches, thanks.
> >
>
> Sorry, I am not sure I understand what patches you want me to post:
>
> WDT patch has already been sent couple of months ago -
> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> Do you want it to be rebased and resend?
>
> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> which is a huge task and not really equal to "Please update the board to
> use CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> DWARF error: could not find abbrev number 3998
> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> <artificial>:(.text+0x5672): undefined reference to
> `ofnode_read_u32_default'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x568c): undefined reference to
> `ofnode_read_u32_default'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> undefined reference to `dm_scan_fdt_dev'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> undefined reference to `dm_scan_fdt_dev'
>
> Fixing those requires enabling of OF_CONTROL and this in turn means the
> board must be migrated to DT, unless I am missing something. That's why
> my "please advice..." stance.
>
> Thanks,
> Ivo

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Wednesday 16 June 2021 06:52:30 Adam Ford wrote:
> Have you experimented with enabling LTO?  I was successful in enabling
> LTO on an OMAP3530 and a DM3730 which really helped reduce the code
> size and I didn't notice any obvious regressions.

Nokia N900 is one of the board where LTO was tested and is enabled.

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4914 bytes --]

On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> > > Hi,
> > > 
> > > On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > > > 
> > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > > > Remove it.
> > > > > > > 
> > > > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > > > 
> > > > > > > I was waiting waiting half of year because other developers did not
> > > > > > > react to issues which were introduced and neither to patches which I
> > > > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > > > half of year until other N900 related patches were merged. So the whole
> > > > > > > slowdown was not caused by me, why it is taking so long.
> > > > > > > 
> > > > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > > > converting code step by step.
> > > > > > > 
> > > > > > > So the ball is not on my side.
> > > > > > 
> > > > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > > > 
> > > > > I don't see any open patches from you that look related to enabling
> > > > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > > > now instead, that's fine too.
> > > > 
> > > 
> > > I tried to migrate the latest master to DM_USB, but unfortunately the
> > > results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> > > have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> > > size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> > > less than 256k of storage space for the u-boot, the produced binary cannot
> > > be used on n900 the same way current (no DM_USB) binary is used.
> > > 
> > > As I see it, there are not much options left - u-boot on N900 is not SPL, so
> > > we can't use OF_PLATDATA, which in turn always links libfdt.
> > > Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> > > the board to be converted to DT and this is way bigger change.
> > > 
> > > Please advice on how to proceed.
> > 
> > Please post your WIP patches, thanks.
> > 
> 
> Sorry, I am not sure I understand what patches you want me to post:
> 
> WDT patch has already been sent couple of months ago -
> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> Do you want it to be rebased and resend?
> 
> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> which is a huge task and not really equal to "Please update the board to use
> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
> 
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> DWARF error: could not find abbrev number 3998
> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> <artificial>:(.text+0x5672): undefined reference to
> `ofnode_read_u32_default'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x568c): undefined reference to
> `ofnode_read_u32_default'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> undefined reference to `dm_scan_fdt_dev'
> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> undefined reference to `dm_scan_fdt_dev'
> 
> Fixing those requires enabling of OF_CONTROL and this in turn means the
> board must be migrated to DT, unless I am missing something. That's why my
> "please advice..." stance.

Please post the patches that bring you to the above link errors, yes,
thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5301 bytes --]

On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
> > Hi,
> > 
> > On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> > > > Hi,
> > > > 
> > > > On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > > > > 
> > > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > > > > Remove it.
> > > > > > > > 
> > > > > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > > > > 
> > > > > > > > I was waiting waiting half of year because other developers did not
> > > > > > > > react to issues which were introduced and neither to patches which I
> > > > > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > > > > half of year until other N900 related patches were merged. So the whole
> > > > > > > > slowdown was not caused by me, why it is taking so long.
> > > > > > > > 
> > > > > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > > > > converting code step by step.
> > > > > > > > 
> > > > > > > > So the ball is not on my side.
> > > > > > > 
> > > > > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > > > > 
> > > > > > I don't see any open patches from you that look related to enabling
> > > > > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > > > > now instead, that's fine too.
> > > > > 
> > > > 
> > > > I tried to migrate the latest master to DM_USB, but unfortunately the
> > > > results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> > > > have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> > > > size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> > > > less than 256k of storage space for the u-boot, the produced binary cannot
> > > > be used on n900 the same way current (no DM_USB) binary is used.
> > > > 
> > > > As I see it, there are not much options left - u-boot on N900 is not SPL, so
> > > > we can't use OF_PLATDATA, which in turn always links libfdt.
> > > > Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> > > > the board to be converted to DT and this is way bigger change.
> > > > 
> > > > Please advice on how to proceed.
> > > 
> > > Please post your WIP patches, thanks.
> > > 
> > 
> > Sorry, I am not sure I understand what patches you want me to post:
> > 
> > WDT patch has already been sent couple of months ago -
> > https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> > Do you want it to be rebased and resend?
> > 
> > DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> > requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> > which is a huge task and not really equal to "Please update the board to use
> > CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
> > 
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > DWARF error: could not find abbrev number 3998
> > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> > <artificial>:(.text+0x5672): undefined reference to
> > `ofnode_read_u32_default'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > <artificial>:(.text+0x568c): undefined reference to
> > `ofnode_read_u32_default'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> > <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> > undefined reference to `dm_scan_fdt_dev'
> > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> > undefined reference to `dm_scan_fdt_dev'
> > 
> > Fixing those requires enabling of OF_CONTROL and this in turn means the
> > board must be migrated to DT, unless I am missing something. That's why my
> > "please advice..." stance.
> 
> Please post the patches that bring you to the above link errors, yes,
> thanks.

To be clearer, finish up a patch that completes the migration but is too
large to install on the hardware so that others can take a look.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

Hi,

On 16.06.21 г. 15:10 ч., Tom Rini wrote:
> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
>>> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>>>> Hi,
>>>>
>>>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>>>
>>>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>>>> Remove it.
>>>>>>>>
>>>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>>>
>>>>>>>> I was waiting waiting half of year because other developers did not
>>>>>>>> react to issues which were introduced and neither to patches which I
>>>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>>>
>>>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>>>> converting code step by step.
>>>>>>>>
>>>>>>>> So the ball is not on my side.
>>>>>>>
>>>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>>>
>>>>>> I don't see any open patches from you that look related to enabling
>>>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>>>> now instead, that's fine too.
>>>>>
>>>>
>>>> I tried to migrate the latest master to DM_USB, but unfortunately the
>>>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>>>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>>>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>>>> less than 256k of storage space for the u-boot, the produced binary cannot
>>>> be used on n900 the same way current (no DM_USB) binary is used.
>>>>
>>>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>>>> we can't use OF_PLATDATA, which in turn always links libfdt.
>>>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>>>> the board to be converted to DT and this is way bigger change.
>>>>
>>>> Please advice on how to proceed.
>>>
>>> Please post your WIP patches, thanks.
>>>
>>
>> Sorry, I am not sure I understand what patches you want me to post:
>>
>> WDT patch has already been sent couple of months ago -
>> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
>> Do you want it to be rebased and resend?
>>
>> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
>> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
>> which is a huge task and not really equal to "Please update the board to use
>> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>>
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> DWARF error: could not find abbrev number 3998
>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
>> <artificial>:(.text+0x5672): undefined reference to
>> `ofnode_read_u32_default'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> <artificial>:(.text+0x568c): undefined reference to
>> `ofnode_read_u32_default'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
>> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
>> undefined reference to `dm_scan_fdt_dev'
>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
>> undefined reference to `dm_scan_fdt_dev'
>>
>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>> board must be migrated to DT, unless I am missing something. That's why my
>> "please advice..." stance.
> 
> Please post the patches that bring you to the above link errors, yes,
> thanks.
> 

diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 3548aab0e1..36ec05a8b3 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -61,6 +61,7 @@ CONFIG_CONS_INDEX=3
  CONFIG_SYS_NS16550=y
  CONFIG_SPI=y
  CONFIG_USB=y
+CONFIG_DM_USB=y
  CONFIG_USB_MUSB_UDC=y
  CONFIG_USB_OMAP3=y
  CONFIG_CFB_CONSOLE=y

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

Hi,

On 16.06.21 г. 15:13 ч., Tom Rini wrote:
> On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
>> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
>>>> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>>>>> Hi,
>>>>>
>>>>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>>>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>>>>
>>>>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>>>>> Remove it.
>>>>>>>>>
>>>>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>>>>
>>>>>>>>> I was waiting waiting half of year because other developers did not
>>>>>>>>> react to issues which were introduced and neither to patches which I
>>>>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>>>>
>>>>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>>>>> converting code step by step.
>>>>>>>>>
>>>>>>>>> So the ball is not on my side.
>>>>>>>>
>>>>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>>>>
>>>>>>> I don't see any open patches from you that look related to enabling
>>>>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>>>>> now instead, that's fine too.
>>>>>>
>>>>>
>>>>> I tried to migrate the latest master to DM_USB, but unfortunately the
>>>>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>>>>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>>>>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>>>>> less than 256k of storage space for the u-boot, the produced binary cannot
>>>>> be used on n900 the same way current (no DM_USB) binary is used.
>>>>>
>>>>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>>>>> we can't use OF_PLATDATA, which in turn always links libfdt.
>>>>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>>>>> the board to be converted to DT and this is way bigger change.
>>>>>
>>>>> Please advice on how to proceed.
>>>>
>>>> Please post your WIP patches, thanks.
>>>>
>>>
>>> Sorry, I am not sure I understand what patches you want me to post:
>>>
>>> WDT patch has already been sent couple of months ago -
>>> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
>>> Do you want it to be rebased and resend?
>>>
>>> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
>>> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
>>> which is a huge task and not really equal to "Please update the board to use
>>> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>>>
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> DWARF error: could not find abbrev number 3998
>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
>>> <artificial>:(.text+0x5672): undefined reference to
>>> `ofnode_read_u32_default'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x568c): undefined reference to
>>> `ofnode_read_u32_default'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
>>> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
>>> undefined reference to `dm_scan_fdt_dev'
>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
>>> undefined reference to `dm_scan_fdt_dev'
>>>
>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>>> board must be migrated to DT, unless I am missing something. That's why my
>>> "please advice..." stance.
>>
>> Please post the patches that bring you to the above link errors, yes,
>> thanks.
> 
> To be clearer, finish up a patch that completes the migration but is too
> large to install on the hardware so that others can take a look.
> 

I am not sure I understand that - a patch that completes the migration 
to DM_USB cannot be done ATM as the binary does not link without 
OF_CONTROL. And I am not going to enable OF_CONTROL as this means I will 
have to migrate everything to DT. That's why I enable DM_USB only - see 
reply to the other mail.

Thanks,
Ivo

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6411 bytes --]

On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote:
> Hi,
> 
> On 16.06.21 г. 15:13 ч., Tom Rini wrote:
> > On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
> > > On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
> > > > Hi,
> > > > 
> > > > On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > > > > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > > > > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > > > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > > > > > > 
> > > > > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > > > > > > Remove it.
> > > > > > > > > > 
> > > > > > > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > > > > > > 
> > > > > > > > > > I was waiting waiting half of year because other developers did not
> > > > > > > > > > react to issues which were introduced and neither to patches which I
> > > > > > > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > > > > > > half of year until other N900 related patches were merged. So the whole
> > > > > > > > > > slowdown was not caused by me, why it is taking so long.
> > > > > > > > > > 
> > > > > > > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > > > > > > converting code step by step.
> > > > > > > > > > 
> > > > > > > > > > So the ball is not on my side.
> > > > > > > > > 
> > > > > > > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > > > > > > 
> > > > > > > > I don't see any open patches from you that look related to enabling
> > > > > > > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > > > > > > now instead, that's fine too.
> > > > > > > 
> > > > > > 
> > > > > > I tried to migrate the latest master to DM_USB, but unfortunately the
> > > > > > results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> > > > > > have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> > > > > > size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> > > > > > less than 256k of storage space for the u-boot, the produced binary cannot
> > > > > > be used on n900 the same way current (no DM_USB) binary is used.
> > > > > > 
> > > > > > As I see it, there are not much options left - u-boot on N900 is not SPL, so
> > > > > > we can't use OF_PLATDATA, which in turn always links libfdt.
> > > > > > Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> > > > > > the board to be converted to DT and this is way bigger change.
> > > > > > 
> > > > > > Please advice on how to proceed.
> > > > > 
> > > > > Please post your WIP patches, thanks.
> > > > > 
> > > > 
> > > > Sorry, I am not sure I understand what patches you want me to post:
> > > > 
> > > > WDT patch has already been sent couple of months ago -
> > > > https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> > > > Do you want it to be rebased and resend?
> > > > 
> > > > DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> > > > requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> > > > which is a huge task and not really equal to "Please update the board to use
> > > > CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
> > > > 
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > DWARF error: could not find abbrev number 3998
> > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> > > > <artificial>:(.text+0x5672): undefined reference to
> > > > `ofnode_read_u32_default'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > <artificial>:(.text+0x568c): undefined reference to
> > > > `ofnode_read_u32_default'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> > > > <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> > > > undefined reference to `dm_scan_fdt_dev'
> > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> > > > undefined reference to `dm_scan_fdt_dev'
> > > > 
> > > > Fixing those requires enabling of OF_CONTROL and this in turn means the
> > > > board must be migrated to DT, unless I am missing something. That's why my
> > > > "please advice..." stance.
> > > 
> > > Please post the patches that bring you to the above link errors, yes,
> > > thanks.
> > 
> > To be clearer, finish up a patch that completes the migration but is too
> > large to install on the hardware so that others can take a look.
> 
> I am not sure I understand that - a patch that completes the migration to
> DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
> And I am not going to enable OF_CONTROL as this means I will have to migrate
> everything to DT. That's why I enable DM_USB only - see reply to the other
> mail.

My advise is to provide a linkable but not runnable (or, only runnable
in QEMU, the problem is the fixed layout of the actual device flash,
right?) patch so that we can figure out how and what needs to be tuned
where so that we can see what to do about this platform.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Merlijn Wajer]

Hi Tom,

On 16/06/2021 19:37, Tom Rini wrote:

>>>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>>>>> board must be migrated to DT, unless I am missing something. That's why my
>>>>> "please advice..." stance.
>>>>
>>>> Please post the patches that bring you to the above link errors, yes,
>>>> thanks.
>>>
>>> To be clearer, finish up a patch that completes the migration but is too
>>> large to install on the hardware so that others can take a look.
>>
>> I am not sure I understand that - a patch that completes the migration to
>> DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
>> And I am not going to enable OF_CONTROL as this means I will have to migrate
>> everything to DT. That's why I enable DM_USB only - see reply to the other
>> mail.
> 
> My advise is to provide a linkable but not runnable (or, only runnable
> in QEMU, the problem is the fixed layout of the actual device flash,
> right?) patch so that we can figure out how and what needs to be tuned
> where so that we can see what to do about this platform.
> 

It looks to me that there are at least two problems:

* Size of the produced u-boot with additional features could be too large
* Porting RX51 to DM_USB seemingly also requires porting RX51 to
device-tree (since OF_CONTROL is required), adding additional complications.

When you ask for patches, are you asking for patches that just enable
DM_USB and stub functions to make the linking succeed (although it
clearly won't result in a functional u-boot), or are you asking for
patches that enable DM_USB and OF_CONTROL, and also port the device to
device tree? To me it seems like you meant the former, but I'd like to
confirm.

Also, I believe Ivaylo and Pali are wondering if porting to DTS is a
hard requirement for porting to DM_USB (since OF_CONTROL would be required)?

Cheers,
Merlijn

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

Hi Tom,

On 16.06.21 г. 20:37 ч., Tom Rini wrote:
> On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 16.06.21 г. 15:13 ч., Tom Rini wrote:
>>> On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
>>>> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
>>>>> Hi,
>>>>>
>>>>> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
>>>>>> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>>>>>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>>>>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>>>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>>>>>>> Remove it.
>>>>>>>>>>>
>>>>>>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>>>>>>
>>>>>>>>>>> I was waiting waiting half of year because other developers did not
>>>>>>>>>>> react to issues which were introduced and neither to patches which I
>>>>>>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>>>>>>
>>>>>>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>>>>>>> converting code step by step.
>>>>>>>>>>>
>>>>>>>>>>> So the ball is not on my side.
>>>>>>>>>>
>>>>>>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>>>>>>
>>>>>>>>> I don't see any open patches from you that look related to enabling
>>>>>>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>>>>>>> now instead, that's fine too.
>>>>>>>>
>>>>>>>
>>>>>>> I tried to migrate the latest master to DM_USB, but unfortunately the
>>>>>>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>>>>>>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>>>>>>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>>>>>>> less than 256k of storage space for the u-boot, the produced binary cannot
>>>>>>> be used on n900 the same way current (no DM_USB) binary is used.
>>>>>>>
>>>>>>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>>>>>>> we can't use OF_PLATDATA, which in turn always links libfdt.
>>>>>>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>>>>>>> the board to be converted to DT and this is way bigger change.
>>>>>>>
>>>>>>> Please advice on how to proceed.
>>>>>>
>>>>>> Please post your WIP patches, thanks.
>>>>>>
>>>>>
>>>>> Sorry, I am not sure I understand what patches you want me to post:
>>>>>
>>>>> WDT patch has already been sent couple of months ago -
>>>>> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
>>>>> Do you want it to be rebased and resend?
>>>>>
>>>>> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
>>>>> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
>>>>> which is a huge task and not really equal to "Please update the board to use
>>>>> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>>>>>
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> DWARF error: could not find abbrev number 3998
>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
>>>>> <artificial>:(.text+0x5672): undefined reference to
>>>>> `ofnode_read_u32_default'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> <artificial>:(.text+0x568c): undefined reference to
>>>>> `ofnode_read_u32_default'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
>>>>> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
>>>>> undefined reference to `dm_scan_fdt_dev'
>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
>>>>> undefined reference to `dm_scan_fdt_dev'
>>>>>
>>>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>>>>> board must be migrated to DT, unless I am missing something. That's why my
>>>>> "please advice..." stance.
>>>>
>>>> Please post the patches that bring you to the above link errors, yes,
>>>> thanks.
>>>
>>> To be clearer, finish up a patch that completes the migration but is too
>>> large to install on the hardware so that others can take a look.
>>
>> I am not sure I understand that - a patch that completes the migration to
>> DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
>> And I am not going to enable OF_CONTROL as this means I will have to migrate
>> everything to DT. That's why I enable DM_USB only - see reply to the other
>> mail.
> 
> My advise is to provide a linkable but not runnable (or, only runnable
> in QEMU, the problem is the fixed layout of the actual device flash,
> right?) patch so that we can figure out how and what needs to be tuned
> where so that we can see what to do about this platform.
> 

What about the following patch (once you confirm I am on the right 
track, I will send a proper patch as well). Enabling thumb is a must, 
otherwise binary does not fit. With the below changes code compiles and 
runs on a real HW:

diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a188ca..c6b042a684 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -956,7 +956,9 @@ U_BOOT_DRIVER(usb_generic_hub) = {
  UCLASS_DRIVER(usb_hub) = {
  	.id		= UCLASS_USB_HUB,
  	.name		= "usb_hub",
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
  	.post_bind	= dm_scan_fdt_dev,
+#endif
  	.post_probe	= usb_hub_post_probe,
  	.child_pre_probe	= usb_child_pre_probe,
  	.per_child_auto	= sizeof(struct usb_device),
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 3548aab0e1..daaf6690ef 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -1,5 +1,5 @@
  CONFIG_ARM=y
-# CONFIG_SYS_THUMB_BUILD is not set
+CONFIG_SYS_THUMB_BUILD=y
  CONFIG_ARCH_OMAP2PLUS=y
  CONFIG_SYS_TEXT_BASE=0x80008000
  CONFIG_NR_DRAM_BANKS=2
@@ -61,6 +61,10 @@ CONFIG_CONS_INDEX=3
  CONFIG_SYS_NS16550=y
  CONFIG_SPI=y
  CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_OF_LIBFDT=y
+CONFIG_OF_LIBFDT_OVERLAY=n
+CONFIG_EFI_LOADER=n
  CONFIG_USB_MUSB_UDC=y
  CONFIG_USB_OMAP3=y
  CONFIG_CFB_CONSOLE=y
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index 5edd4e4135..e7213143c4 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -2,7 +2,7 @@
  #
  # Copyright (c) 2013 Google, Inc

-obj-y	+= device.o fdtaddr.o lists.o root.o uclass.o util.o
+obj-y	+= device.o fdtaddr.o lists.o root.o uclass.o util.o ofnode.o
  obj-$(CONFIG_$(SPL_TPL_)ACPIGEN) += acpi.o
  obj-$(CONFIG_DEVRES) += devres.o
  obj-$(CONFIG_$(SPL_)DM_DEVICE_REMOVE)	+= device-remove.o
@@ -15,6 +15,6 @@ obj-$(CONFIG_$(SPL_)OF_LIVE) += of_access.o of_addr.o
  ifndef CONFIG_DM_DEV_READ_INLINE
  obj-$(CONFIG_OF_CONTROL) += read.o
  endif
-obj-$(CONFIG_OF_CONTROL) += of_extra.o ofnode.o read_extra.o
+obj-$(CONFIG_OF_CONTROL) += of_extra.o read_extra.o

  ccflags-$(CONFIG_DM_DEBUG) += -DDEBUG
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index e3b616c326..71dc578550 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -770,6 +770,7 @@ int usb_detect_change(void)

  static int usb_child_post_bind(struct udevice *dev)
  {
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
  	struct usb_dev_plat *plat = dev_get_parent_plat(dev);
  	int val;

@@ -787,7 +788,7 @@ static int usb_child_post_bind(struct udevice *dev)
  		plat->id.match_flags |= USB_DEVICE_ID_MATCH_INT_CLASS;
  		plat->id.bInterfaceClass = val;
  	}
-
+#endif
  	return 0;
  }

@@ -848,7 +849,9 @@ UCLASS_DRIVER(usb) = {
  	.id		= UCLASS_USB,
  	.name		= "usb",
  	.flags		= DM_UC_FLAG_SEQ_ALIAS,
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
  	.post_bind	= dm_scan_fdt_dev,
+#endif
  	.priv_auto	= sizeof(struct usb_uclass_priv),
  	.per_child_auto	= sizeof(struct usb_device),
  	.per_device_auto	= sizeof(struct usb_bus_priv),

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7659 bytes --]

On Thu, Jun 17, 2021 at 12:03:15AM +0300, Ivaylo Dimitrov wrote:
> Hi Tom,
> 
> On 16.06.21 г. 20:37 ч., Tom Rini wrote:
> > On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote:
> > > Hi,
> > > 
> > > On 16.06.21 г. 15:13 ч., Tom Rini wrote:
> > > > On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
> > > > > On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > > > > > > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > > > > > > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > > > > > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > > > > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > > > > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > > > > > > > > Remove it.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > > > > > > > > 
> > > > > > > > > > > > I was waiting waiting half of year because other developers did not
> > > > > > > > > > > > react to issues which were introduced and neither to patches which I
> > > > > > > > > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > > > > > > > > half of year until other N900 related patches were merged. So the whole
> > > > > > > > > > > > slowdown was not caused by me, why it is taking so long.
> > > > > > > > > > > > 
> > > > > > > > > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > > > > > > > > converting code step by step.
> > > > > > > > > > > > 
> > > > > > > > > > > > So the ball is not on my side.
> > > > > > > > > > > 
> > > > > > > > > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > > > > > > > > 
> > > > > > > > > > I don't see any open patches from you that look related to enabling
> > > > > > > > > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > > > > > > > > now instead, that's fine too.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I tried to migrate the latest master to DM_USB, but unfortunately the
> > > > > > > > results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> > > > > > > > have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> > > > > > > > size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> > > > > > > > less than 256k of storage space for the u-boot, the produced binary cannot
> > > > > > > > be used on n900 the same way current (no DM_USB) binary is used.
> > > > > > > > 
> > > > > > > > As I see it, there are not much options left - u-boot on N900 is not SPL, so
> > > > > > > > we can't use OF_PLATDATA, which in turn always links libfdt.
> > > > > > > > Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> > > > > > > > the board to be converted to DT and this is way bigger change.
> > > > > > > > 
> > > > > > > > Please advice on how to proceed.
> > > > > > > 
> > > > > > > Please post your WIP patches, thanks.
> > > > > > > 
> > > > > > 
> > > > > > Sorry, I am not sure I understand what patches you want me to post:
> > > > > > 
> > > > > > WDT patch has already been sent couple of months ago -
> > > > > > https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> > > > > > Do you want it to be rebased and resend?
> > > > > > 
> > > > > > DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> > > > > > requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> > > > > > which is a huge task and not really equal to "Please update the board to use
> > > > > > CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
> > > > > > 
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > DWARF error: could not find abbrev number 3998
> > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> > > > > > <artificial>:(.text+0x5672): undefined reference to
> > > > > > `ofnode_read_u32_default'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > <artificial>:(.text+0x568c): undefined reference to
> > > > > > `ofnode_read_u32_default'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> > > > > > <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> > > > > > undefined reference to `dm_scan_fdt_dev'
> > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> > > > > > undefined reference to `dm_scan_fdt_dev'
> > > > > > 
> > > > > > Fixing those requires enabling of OF_CONTROL and this in turn means the
> > > > > > board must be migrated to DT, unless I am missing something. That's why my
> > > > > > "please advice..." stance.
> > > > > 
> > > > > Please post the patches that bring you to the above link errors, yes,
> > > > > thanks.
> > > > 
> > > > To be clearer, finish up a patch that completes the migration but is too
> > > > large to install on the hardware so that others can take a look.
> > > 
> > > I am not sure I understand that - a patch that completes the migration to
> > > DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
> > > And I am not going to enable OF_CONTROL as this means I will have to migrate
> > > everything to DT. That's why I enable DM_USB only - see reply to the other
> > > mail.
> > 
> > My advise is to provide a linkable but not runnable (or, only runnable
> > in QEMU, the problem is the fixed layout of the actual device flash,
> > right?) patch so that we can figure out how and what needs to be tuned
> > where so that we can see what to do about this platform.
> > 
> 
> What about the following patch (once you confirm I am on the right track, I
> will send a proper patch as well). Enabling thumb is a must, otherwise
> binary does not fit. With the below changes code compiles and runs on a real
> HW:

Wait, why is thumb disabled?  That's something I'd really like to know
why on as my first guess is there's units with old enough cores that
have some thumb errata maybe?  For the second part, how are you binding
the device?  And oh, we didn't disable the EFI loader support already?
Yeah, that would be another pretty easy choice to win back a bunch of
space.  So yes, this is certainly on the right track, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

On Wed, Jun 16, 2021 at 10:44:52PM +0200, Merlijn Wajer wrote:
> Hi Tom,
> 
> On 16/06/2021 19:37, Tom Rini wrote:
> 
> >>>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
> >>>>> board must be migrated to DT, unless I am missing something. That's why my
> >>>>> "please advice..." stance.
> >>>>
> >>>> Please post the patches that bring you to the above link errors, yes,
> >>>> thanks.
> >>>
> >>> To be clearer, finish up a patch that completes the migration but is too
> >>> large to install on the hardware so that others can take a look.
> >>
> >> I am not sure I understand that - a patch that completes the migration to
> >> DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
> >> And I am not going to enable OF_CONTROL as this means I will have to migrate
> >> everything to DT. That's why I enable DM_USB only - see reply to the other
> >> mail.
> > 
> > My advise is to provide a linkable but not runnable (or, only runnable
> > in QEMU, the problem is the fixed layout of the actual device flash,
> > right?) patch so that we can figure out how and what needs to be tuned
> > where so that we can see what to do about this platform.
> > 
> 
> It looks to me that there are at least two problems:
> 
> * Size of the produced u-boot with additional features could be too large
> * Porting RX51 to DM_USB seemingly also requires porting RX51 to
> device-tree (since OF_CONTROL is required), adding additional complications.
> 
> When you ask for patches, are you asking for patches that just enable
> DM_USB and stub functions to make the linking succeed (although it
> clearly won't result in a functional u-boot), or are you asking for
> patches that enable DM_USB and OF_CONTROL, and also port the device to
> device tree? To me it seems like you meant the former, but I'd like to
> confirm.
> 
> Also, I believe Ivaylo and Pali are wondering if porting to DTS is a
> hard requirement for porting to DM_USB (since OF_CONTROL would be required)?

So, part of the high level answer here is that long term, yes, enabling
DM for everything is required.  That may mean additional infrastructure
work, if we don't already have all of the knobs in place today to let
space constrained platforms like this continue to work.  Does that mean
we _have_to_ have OF_CONTROL?  Well, today we don't have platdata for
non-SPL/TPL.  Saying we can't support this platform without adding as an
option and then enablig OF_PLATDATA for U-Boot itself is something to
bring up on the U-Boot mailing list and cc the relevant custodians.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Wednesday 16 June 2021 17:12:13 Tom Rini wrote:
> Wait, why is thumb disabled?  That's something I'd really like to know
> why on as my first guess is there's units with old enough cores that
> have some thumb errata maybe?

IIRC we disabled at time when N900 support was merged into U-Boot (about
10 years ago) as built binary did not work on real N900 HW. Non-thumb
build work fine.

I thought it was due to thumb errata but yesterday I was told that thumb
errata affects running system only when virtual memory and context
switches are used. And correct me if I'm wrong, but u-boot is not using
virtual memory mapping and neither multiprocessing context switches.

So it looks like that at that time (10 years ago) there was another bug
in u-boot which caused that thumb build was non-working.

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Wed, Jun 16, 2021 at 11:16:32PM +0200, Pali Rohár wrote:
> On Wednesday 16 June 2021 17:12:13 Tom Rini wrote:
> > Wait, why is thumb disabled?  That's something I'd really like to know
> > why on as my first guess is there's units with old enough cores that
> > have some thumb errata maybe?
> 
> IIRC we disabled at time when N900 support was merged into U-Boot (about
> 10 years ago) as built binary did not work on real N900 HW. Non-thumb
> build work fine.
> 
> I thought it was due to thumb errata but yesterday I was told that thumb
> errata affects running system only when virtual memory and context
> switches are used. And correct me if I'm wrong, but u-boot is not using
> virtual memory mapping and neither multiprocessing context switches.
> 
> So it looks like that at that time (10 years ago) there was another bug
> in u-boot which caused that thumb build was non-working.

Thanks for explaining, yes, we should be able to enable thumb and
disable EFI and see just how close things are again to the size limit.

Oh, and we have things set such that the hooks to cause link time errors
on size overflow are enabled here, right?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Pali Rohár]

On Wednesday 16 June 2021 17:20:20 Tom Rini wrote:
> On Wed, Jun 16, 2021 at 11:16:32PM +0200, Pali Rohár wrote:
> > On Wednesday 16 June 2021 17:12:13 Tom Rini wrote:
> > > Wait, why is thumb disabled?  That's something I'd really like to know
> > > why on as my first guess is there's units with old enough cores that
> > > have some thumb errata maybe?
> > 
> > IIRC we disabled at time when N900 support was merged into U-Boot (about
> > 10 years ago) as built binary did not work on real N900 HW. Non-thumb
> > build work fine.
> > 
> > I thought it was due to thumb errata but yesterday I was told that thumb
> > errata affects running system only when virtual memory and context
> > switches are used. And correct me if I'm wrong, but u-boot is not using
> > virtual memory mapping and neither multiprocessing context switches.
> > 
> > So it looks like that at that time (10 years ago) there was another bug
> > in u-boot which caused that thumb build was non-working.
> 
> Thanks for explaining, yes, we should be able to enable thumb and

This needs to be tested on N900 hw if it really works.

> disable EFI and see just how close things are again to the size limit.

EFI is not used on N900 and I'm not aware why it is enabled. Maybe
somebody proactively enabled it and nobody noticed? So very good
candidate for immediate disabling to reduce space.

> Oh, and we have things set such that the hooks to cause link time errors
> on size overflow are enabled here, right?

Seems that link time errors are not enabled. But "integration" test for
N900 which is running on Azure is checking this enforcement. Just
because generating final MTD image (for running test) fails.

Also you can run this test manually on local computer:

./test/nokia_rx51_test.sh

So thanks to Azure CI testing, we are sure if tests passes, N900 code is
working fine (at least in qemu) and also has "correct" size.

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Ivaylo Dimitrov]

On 17.06.21 г. 0:12 ч., Tom Rini wrote:
> On Thu, Jun 17, 2021 at 12:03:15AM +0300, Ivaylo Dimitrov wrote:
>> Hi Tom,
>>
>> On 16.06.21 г. 20:37 ч., Tom Rini wrote:
>>> On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote:
>>>> Hi,
>>>>
>>>> On 16.06.21 г. 15:13 ч., Tom Rini wrote:
>>>>> On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
>>>>>> On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 15.06.21 г. 15:34 ч., Tom Rini wrote:
>>>>>>>> On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
>>>>>>>>>> On Friday 21 May 2021 10:44:18 Tom Rini wrote:
>>>>>>>>>>> On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
>>>>>>>>>>>> On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
>>>>>>>>>>>>>> This board has not been converted to CONFIG_DM_USB by the deadline.
>>>>>>>>>>>>>> Remove it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm very disappointed that you want to remove Nokia N900 from U-Boot.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was waiting waiting half of year because other developers did not
>>>>>>>>>>>>> react to issues which were introduced and neither to patches which I
>>>>>>>>>>>>> sent (+ trying to remind open issues). And also I was waiting another
>>>>>>>>>>>>> half of year until other N900 related patches were merged. So the whole
>>>>>>>>>>>>> slowdown was not caused by me, why it is taking so long.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now there is still one N900 DM related patch waiting for review. I'm
>>>>>>>>>>>>> converting code step by step.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the ball is not on my side.
>>>>>>>>>>>>
>>>>>>>>>>>> So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
>>>>>>>>>>>
>>>>>>>>>>> I don't see any open patches from you that look related to enabling
>>>>>>>>>>> DM_USB on the platform.  If you want to disable USB on the platform for
>>>>>>>>>>> now instead, that's fine too.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I tried to migrate the latest master to DM_USB, but unfortunately the
>>>>>>>>> results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
>>>>>>>>> have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
>>>>>>>>> size of the u-boot binary, so it becomes 370284 bytes. Given that we have
>>>>>>>>> less than 256k of storage space for the u-boot, the produced binary cannot
>>>>>>>>> be used on n900 the same way current (no DM_USB) binary is used.
>>>>>>>>>
>>>>>>>>> As I see it, there are not much options left - u-boot on N900 is not SPL, so
>>>>>>>>> we can't use OF_PLATDATA, which in turn always links libfdt.
>>>>>>>>> Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
>>>>>>>>> the board to be converted to DT and this is way bigger change.
>>>>>>>>>
>>>>>>>>> Please advice on how to proceed.
>>>>>>>>
>>>>>>>> Please post your WIP patches, thanks.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry, I am not sure I understand what patches you want me to post:
>>>>>>>
>>>>>>> WDT patch has already been sent couple of months ago -
>>>>>>> https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
>>>>>>> Do you want it to be rebased and resend?
>>>>>>>
>>>>>>> DM_USB, I just started writing one and I immediately hit the OF_CONTROL
>>>>>>> requirement. Enabling OF_CONTROL requires a full blown migration to DT,
>>>>>>> which is a huge task and not really equal to "Please update the board to use
>>>>>>> CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
>>>>>>>
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> DWARF error: could not find abbrev number 3998
>>>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
>>>>>>> <artificial>:(.text+0x5672): undefined reference to
>>>>>>> `ofnode_read_u32_default'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> <artificial>:(.text+0x568c): undefined reference to
>>>>>>> `ofnode_read_u32_default'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
>>>>>>> <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
>>>>>>> undefined reference to `dm_scan_fdt_dev'
>>>>>>> /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
>>>>>>> /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
>>>>>>> undefined reference to `dm_scan_fdt_dev'
>>>>>>>
>>>>>>> Fixing those requires enabling of OF_CONTROL and this in turn means the
>>>>>>> board must be migrated to DT, unless I am missing something. That's why my
>>>>>>> "please advice..." stance.
>>>>>>
>>>>>> Please post the patches that bring you to the above link errors, yes,
>>>>>> thanks.
>>>>>
>>>>> To be clearer, finish up a patch that completes the migration but is too
>>>>> large to install on the hardware so that others can take a look.
>>>>
>>>> I am not sure I understand that - a patch that completes the migration to
>>>> DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
>>>> And I am not going to enable OF_CONTROL as this means I will have to migrate
>>>> everything to DT. That's why I enable DM_USB only - see reply to the other
>>>> mail.
>>>
>>> My advise is to provide a linkable but not runnable (or, only runnable
>>> in QEMU, the problem is the fixed layout of the actual device flash,
>>> right?) patch so that we can figure out how and what needs to be tuned
>>> where so that we can see what to do about this platform.
>>>
>>
>> What about the following patch (once you confirm I am on the right track, I
>> will send a proper patch as well). Enabling thumb is a must, otherwise
>> binary does not fit. With the below changes code compiles and runs on a real
>> HW:
> 
> Wait, why is thumb disabled?  That's something I'd really like to know
> why on as my first guess is there's units with old enough cores that
> have some thumb errata maybe? 

omap3 in N900 suffers from ARM errata 430973, I guess that's why -mthumb 
was disabled back then. I implemented N900 specific workaround to set 
the IBE bit in ACR in the board code, but I don't see flush BTAC/BTB 
being executed on context switch (if there are context switches at all). 
The only places I was able to find that flush BTAC/BTB instruction are 
on startup (cpu_init_cp15()) and cache invalidate 
(invalidate_icache_all()).

BTW the code in cpu_init_cp15() is buggy, as flush is executed before 
IBE bit in ACR is set, making that flush effectively a noop on boards 
where IBE bit was not set by the previous stage loader, but that's 
another story not affecting N900 :).

So, as soon as there are no context switches in u-boot that may land 
different code on a same physical address, we should be safe. Could you 
confirm this is the case? Is there virtual addressing? Multiple processes?

> For the second part, how are you binding
> the device?  And oh, we didn't disable the EFI loader support already?

Yeah, looks like selecting libfdt automagically selects a whole bunch of 
other things (like CMD_FDT and OF_LIBFDT_OVERLAY)

> Yeah, that would be another pretty easy choice to win back a bunch of
> space.  So yes, this is certainly on the right track, thanks!
> 

Ok, we'll send a proper patch series as soon as it is confirmed that it 
is safe to enable -mthumb.

In the meanwhile, could you please have a look at the WDT patch Pali 
posted back then?

Thanks,
Ivo

Re: [maemo-leste] [PATCH] arm: Remove nokia_rx51 board

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 10008 bytes --]

On Thu, Jun 17, 2021 at 10:18:07AM +0300, Ivaylo Dimitrov wrote:
> 
> 
> On 17.06.21 г. 0:12 ч., Tom Rini wrote:
> > On Thu, Jun 17, 2021 at 12:03:15AM +0300, Ivaylo Dimitrov wrote:
> > > Hi Tom,
> > > 
> > > On 16.06.21 г. 20:37 ч., Tom Rini wrote:
> > > > On Wed, Jun 16, 2021 at 08:25:28PM +0300, Ivaylo Dimitrov wrote:
> > > > > Hi,
> > > > > 
> > > > > On 16.06.21 г. 15:13 ч., Tom Rini wrote:
> > > > > > On Wed, Jun 16, 2021 at 08:10:08AM -0400, Tom Rini wrote:
> > > > > > > On Wed, Jun 16, 2021 at 09:02:16AM +0300, Ivaylo Dimitrov wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 15.06.21 г. 15:34 ч., Tom Rini wrote:
> > > > > > > > > On Tue, Jun 15, 2021 at 08:40:30AM +0300, Ivaylo Dimitrov wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On 22.05.21 г. 0:36 ч., Pali Rohár wrote:
> > > > > > > > > > > On Friday 21 May 2021 10:44:18 Tom Rini wrote:
> > > > > > > > > > > > On Wed, May 19, 2021 at 11:52:03AM -0400, Tom Rini wrote:
> > > > > > > > > > > > > On Wed, May 19, 2021 at 03:27:48PM +0200, Pali Rohár wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Tuesday 18 May 2021 21:26:40 Tom Rini wrote:
> > > > > > > > > > > > > > > This board has not been converted to CONFIG_DM_USB by the deadline.
> > > > > > > > > > > > > > > Remove it.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I'm very disappointed that you want to remove Nokia N900 from U-Boot.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I was waiting waiting half of year because other developers did not
> > > > > > > > > > > > > > react to issues which were introduced and neither to patches which I
> > > > > > > > > > > > > > sent (+ trying to remind open issues). And also I was waiting another
> > > > > > > > > > > > > > half of year until other N900 related patches were merged. So the whole
> > > > > > > > > > > > > > slowdown was not caused by me, why it is taking so long.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Now there is still one N900 DM related patch waiting for review. I'm
> > > > > > > > > > > > > > converting code step by step.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So the ball is not on my side.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So, what patch(es) need to be applied to get DM_USB enabled?  Thanks.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't see any open patches from you that look related to enabling
> > > > > > > > > > > > DM_USB on the platform.  If you want to disable USB on the platform for
> > > > > > > > > > > > now instead, that's fine too.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I tried to migrate the latest master to DM_USB, but unfortunately the
> > > > > > > > > > results are pretty much sad - adding OF_CONTROL (which is a prerequisite to
> > > > > > > > > > have DM_USB IIUC) and OF_BOARD (so binary to be compiled), adds ~100k to the
> > > > > > > > > > size of the u-boot binary, so it becomes 370284 bytes. Given that we have
> > > > > > > > > > less than 256k of storage space for the u-boot, the produced binary cannot
> > > > > > > > > > be used on n900 the same way current (no DM_USB) binary is used.
> > > > > > > > > > 
> > > > > > > > > > As I see it, there are not much options left - u-boot on N900 is not SPL, so
> > > > > > > > > > we can't use OF_PLATDATA, which in turn always links libfdt.
> > > > > > > > > > Also, if I read the code (usb-uclass.c) correctly, enabling DM_USB requires
> > > > > > > > > > the board to be converted to DT and this is way bigger change.
> > > > > > > > > > 
> > > > > > > > > > Please advice on how to proceed.
> > > > > > > > > 
> > > > > > > > > Please post your WIP patches, thanks.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Sorry, I am not sure I understand what patches you want me to post:
> > > > > > > > 
> > > > > > > > WDT patch has already been sent couple of months ago -
> > > > > > > > https://lists.denx.de/pipermail/u-boot/2021-March/443868.html
> > > > > > > > Do you want it to be rebased and resend?
> > > > > > > > 
> > > > > > > > DM_USB, I just started writing one and I immediately hit the OF_CONTROL
> > > > > > > > requirement. Enabling OF_CONTROL requires a full blown migration to DT,
> > > > > > > > which is a huge task and not really equal to "Please update the board to use
> > > > > > > > CONFIG_DM_USB...". Without OF_CONTROL, I simply get link failures:
> > > > > > > > 
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > DWARF error: could not find abbrev number 3998
> > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_child_post_bind':
> > > > > > > > <artificial>:(.text+0x5672): undefined reference to
> > > > > > > > `ofnode_read_u32_default'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > <artificial>:(.text+0x568c): undefined reference to
> > > > > > > > `ofnode_read_u32_default'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o: in function `usb_scan_device':
> > > > > > > > <artificial>:(.text+0x6c84): undefined reference to `ofnode_first_subnode'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > <artificial>:(.text+0x6c96): undefined reference to `ofnode_read_u32'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > <artificial>:(.text+0x6ca4): undefined reference to `ofnode_next_subnode'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb+0x8):
> > > > > > > > undefined reference to `dm_scan_fdt_dev'
> > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld:
> > > > > > > > /tmp/cc0BOqms.ltrans0.ltrans.o:(.u_boot_list_2_uclass_driver_2_usb_hub+0x8):
> > > > > > > > undefined reference to `dm_scan_fdt_dev'
> > > > > > > > 
> > > > > > > > Fixing those requires enabling of OF_CONTROL and this in turn means the
> > > > > > > > board must be migrated to DT, unless I am missing something. That's why my
> > > > > > > > "please advice..." stance.
> > > > > > > 
> > > > > > > Please post the patches that bring you to the above link errors, yes,
> > > > > > > thanks.
> > > > > > 
> > > > > > To be clearer, finish up a patch that completes the migration but is too
> > > > > > large to install on the hardware so that others can take a look.
> > > > > 
> > > > > I am not sure I understand that - a patch that completes the migration to
> > > > > DM_USB cannot be done ATM as the binary does not link without OF_CONTROL.
> > > > > And I am not going to enable OF_CONTROL as this means I will have to migrate
> > > > > everything to DT. That's why I enable DM_USB only - see reply to the other
> > > > > mail.
> > > > 
> > > > My advise is to provide a linkable but not runnable (or, only runnable
> > > > in QEMU, the problem is the fixed layout of the actual device flash,
> > > > right?) patch so that we can figure out how and what needs to be tuned
> > > > where so that we can see what to do about this platform.
> > > > 
> > > 
> > > What about the following patch (once you confirm I am on the right track, I
> > > will send a proper patch as well). Enabling thumb is a must, otherwise
> > > binary does not fit. With the below changes code compiles and runs on a real
> > > HW:
> > 
> > Wait, why is thumb disabled?  That's something I'd really like to know
> > why on as my first guess is there's units with old enough cores that
> > have some thumb errata maybe?
> 
> omap3 in N900 suffers from ARM errata 430973, I guess that's why -mthumb was
> disabled back then. I implemented N900 specific workaround to set the IBE
> bit in ACR in the board code, but I don't see flush BTAC/BTB being executed
> on context switch (if there are context switches at all). The only places I
> was able to find that flush BTAC/BTB instruction are on startup
> (cpu_init_cp15()) and cache invalidate (invalidate_icache_all()).
> 
> BTW the code in cpu_init_cp15() is buggy, as flush is executed before IBE
> bit in ACR is set, making that flush effectively a noop on boards where IBE
> bit was not set by the previous stage loader, but that's another story not
> affecting N900 :).

A separate thread / patch on that would be much appreciated :)

> So, as soon as there are no context switches in u-boot that may land
> different code on a same physical address, we should be safe. Could you
> confirm this is the case? Is there virtual addressing? Multiple processes?

The only place I'm not 100% sure we wouldn't have virtual addressing
would be when you start to involve the EFI loader and in turn EFI
applications are running.  But we're specifically disabling this here
(and I don't think it's useful on this era hardware anyhow).

> > For the second part, how are you binding
> > the device?  And oh, we didn't disable the EFI loader support already?
> 
> Yeah, looks like selecting libfdt automagically selects a whole bunch of
> other things (like CMD_FDT and OF_LIBFDT_OVERLAY)
> 
> > Yeah, that would be another pretty easy choice to win back a bunch of
> > space.  So yes, this is certainly on the right track, thanks!
> > 
> 
> Ok, we'll send a proper patch series as soon as it is confirmed that it is
> safe to enable -mthumb.

Thanks.

> In the meanwhile, could you please have a look at the WDT patch Pali posted
> back then?

It's been merged to -next for a little while now, via the TI tree.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]