Skip to contentSkip to conversation

igep00x0: disable CONFIG_DISPLAY_BOARDINFO

PATCH Superseded Ladislav Michl 4 participants 28 messages Sep 20, 2016 – Nov 13, 2016 1 message not in the archive

lore
Share & tools
lore

Ladislav Michl

author
#0 lore raw

PATCH 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as there's no known way to distinguish between them. Also saves few bytes as a bonus.

Signed-off-by Ladislav Michl <[email protected]>
---
 board/isee/igep00x0/igep00x0.c   | 18 ------------------
 include/configs/omap3_igep00x0.h |  5 +----
 2 files changed, 1 insertion(+), 22 deletions(-)
board/isee/igep00x0/igep00x0.c +0 -18
index 808955e..71688cc 100644
@@ -27,24 +27,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-const omap3_sysinfo sysinfo = {
-	DDR_STACKED,
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
-	"IGEPv2",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
-	"IGEP COM MODULE/ELECTRON",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
-	"IGEP COM PROTON",
-#endif
-#if defined(CONFIG_ENV_IS_IN_ONENAND)
-	"ONENAND",
-#else
-	"NAND",
-#endif
-};
-
 static const struct ns16550_platdata igep_serial = {
 	.base = OMAP34XX_UART3,
 	.reg_shift = 2,
include/configs/omap3_igep00x0.h +1 -4
index 1f30710..2ae9737 100644
@@ -23,11 +23,8 @@
 #undef CONFIG_SPL_TEXT_BASE
 #define CONFIG_SPL_TEXT_BASE		0x40200000
 
-/*
- * Display CPU and Board information
- */
+/* Display CPU information */
 #define CONFIG_DISPLAY_CPUINFO		1
-#define CONFIG_DISPLAY_BOARDINFO	1
 
 #define CONFIG_MISC_INIT_R
Signature · 1 line
2.1.4
author
#1 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Update defconfigs and drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>
---
 configs/igep0030_defconfig      |  5 ++++-
 configs/igep0030_nand_defconfig | 30 ------------------------------
 configs/igep0032_defconfig      |  4 +++-
 3 files changed, 7 insertions(+), 32 deletions(-)
 delete mode 100644 configs/igep0030_nand_defconfig
configs/igep0030_defconfig +4 -1
index 66371d6..eb7a28f 100644
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
+CONFIG_BOOTDELAY=3
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y

@@ -26,5 +28,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
configs/igep0030_nand_defconfig deleted +0 -30
deleted file mode 100644
index f63bcac..0000000
@@ -1,30 +0,0 @@
-CONFIG_ARM=y
-CONFIG_OMAP34XX=y
-# CONFIG_SPL_EXT_SUPPORT is not set
-CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND"
-CONFIG_VERSION_VARIABLE=y
-CONFIG_SPL=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMLS is not set
-CONFIG_CMD_ASKENV=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_SYS_NS16550=y
-CONFIG_OF_LIBFDT=y
configs/igep0032_defconfig +3 -1
index 991d9d7..eb7a28f 100644
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
+CONFIG_BOOTDELAY=3
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
Signature · 1 line
2.1.4
#2 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 16 lines · Ladislav Michl

Update defconfigs and drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>
---
 configs/igep0030_defconfig      |  5 ++++-
 configs/igep0030_nand_defconfig | 30 ------------------------------
 configs/igep0032_defconfig      |  4 +++-
 3 files changed, 7 insertions(+), 32 deletions(-)
 delete mode 100644 configs/igep0030_nand_defconfig
configs/igep0030_defconfig +0 -0
index 66371d6..eb7a28f 100644

configs/igep0030_defconfig CONFIG_ARM=y · line 6

Quoted 6 lines
configs/igep0030_defconfig +2 -1
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"

Since you're even changing MACH_TYPE here, do we really need to be setting this? For both defconfigs, even. Thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160920/4c3cd038/attachment.sig>
author
#3 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 12 lines · Tom Rini
Quoted 11 lines · Ladislav Michl

Update defconfigs and drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>
---
 configs/igep0030_defconfig      |  5 ++++-
 configs/igep0030_nand_defconfig | 30 ------------------------------
 configs/igep0032_defconfig      |  4 +++-
 3 files changed, 7 insertions(+), 32 deletions(-)
 delete mode 100644 configs/igep0030_nand_defconfig
Quoted 14 lines

configs/igep0030_defconfig CONFIG_ARM=y · line 6

Quoted 11 lines
configs/igep0030_defconfig +2 -1
index 66371d6..eb7a28f 100644
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"

Since you're even changing MACH_TYPE here, do we really need to be setting this? For both defconfigs, even. Thanks!

Gah... I have to screw it up while resolving conflicts with upstream changes. Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

ladis

#4 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 28 lines · Ladislav Michl
Quoted 12 lines · Tom Rini
Quoted 11 lines · Ladislav Michl

Update defconfigs and drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>
---
 configs/igep0030_defconfig      |  5 ++++-
 configs/igep0030_nand_defconfig | 30 ------------------------------
 configs/igep0032_defconfig      |  4 +++-
 3 files changed, 7 insertions(+), 32 deletions(-)
 delete mode 100644 configs/igep0030_nand_defconfig
Quoted 14 lines

configs/igep0030_defconfig CONFIG_ARM=y · line 6

Quoted 11 lines
configs/igep0030_defconfig +2 -1
index 66371d6..eb7a28f 100644
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"

Since you're even changing MACH_TYPE here, do we really need to be setting this? For both defconfigs, even. Thanks!

Quoted 2 lines

Gah... I have to screw it up while resolving conflicts with upstream changes. Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

But why do we even need to set MACH_TYPE these days?

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160920/7799d768/attachment.sig>
author
#5 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 1 line · Tom Rini

On Wed, Sep 21, 2016 at 12:44:17AM +0200, Ladislav Michl wrote:

[snip]

Quoted 4 lines
Quoted 2 lines

Gah... I have to screw it up while resolving conflicts with upstream changes. Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

ladis

#6 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 6 lines · Ladislav Michl
Quoted 1 line · Tom Rini

On Wed, Sep 21, 2016 at 12:44:17AM +0200, Ladislav Michl wrote:

[snip]

Quoted 3 lines
Quoted 2 lines

Gah... I have to screw it up while resolving conflicts with upstream changes. Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160920/ede4bccb/attachment.sig>
author
#7 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 2 lines · Tom Rini
Quoted 1 line · Ladislav Michl

On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:

[snip]

Quoted 9 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

ladis

#8 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 11 lines · Tom Rini
Quoted 2 lines · Ladislav Michl
Quoted 1 line · Tom Rini

[snip]

Quoted 7 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

Quoted 8 lines
Quoted 2 lines

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Quoted 4 lines

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

That is what I would like to see someday ;) All OMAP3 based boards sharing the same binary and configure U-Boot using FDT.

Quoted 1 line

ladis

#9 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 22 lines · Enric Balletbo Serra

Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 11 lines · Tom Rini
Quoted 2 lines · Ladislav Michl
Quoted 1 line · Tom Rini

[snip]

Quoted 7 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

Quoted 7 lines
Quoted 2 lines

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

Quoted 5 lines

There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Note that the different beagleboard used GPIOs to tell which platform is which :)

Quoted 6 lines
Quoted 3 lines

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

That is what I would like to see someday ;) All OMAP3 based boards sharing the same binary and configure U-Boot using FDT.

The probably trickiest part here is DDR config, which still punts things down to a board specific MLO. But within an SoC this is probably a lot closer than people might think.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160921/609cedee/attachment.sig>
#10 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

2016-09-21 14:51 GMT+02:00 Tom Rini <[email protected]>:

Quoted 23 lines · Enric Balletbo Serra
Quoted 22 lines

Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 18 lines · Tom Rini
Quoted 2 lines · Ladislav Michl
Quoted 1 line · Tom Rini

[snip]

Quoted 9 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

Quoted 9 lines
Quoted 5 lines

There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Note that the different beagleboard used GPIOs to tell which platform is which :)

Yes, but if I'm not mistaken you have different GPIOs for different hardware revisions of Beagleboard. For IGEPv2 this is also true, you have different GPIOs for different hardware revisions of IGEPv2. But we're talking about join two completely different boards, i.e join IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to join Beagleboard with OMAP3 OVERO COM.

OTOH I think the Ladis work trying to join the IGEP boards is really interesting, just want to look deeper :)

Quoted 13 lines
Quoted 6 lines
Quoted 3 lines

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

That is what I would like to see someday ;) All OMAP3 based boards sharing the same binary and configure U-Boot using FDT.

The probably trickiest part here is DDR config, which still punts things down to a board specific MLO. But within an SoC this is probably a lot closer than people might think.

--
Tom

#11 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 40 lines · Enric Balletbo Serra

2016-09-21 14:51 GMT+02:00 Tom Rini <[email protected]>:

Quoted 23 lines · Enric Balletbo Serra
Quoted 22 lines

Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 18 lines · Tom Rini
Quoted 2 lines · Ladislav Michl
Quoted 1 line · Tom Rini

[snip]

Quoted 9 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

Quoted 8 lines
Quoted 5 lines

There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Note that the different beagleboard used GPIOs to tell which platform is which :)

Yes, but if I'm not mistaken you have different GPIOs for different hardware revisions of Beagleboard. For IGEPv2 this is also true, you have different GPIOs for different hardware revisions of IGEPv2. But we're talking about join two completely different boards, i.e join IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to join Beagleboard with OMAP3 OVERO COM.

Quoted 2 lines

OTOH I think the Ladis work trying to join the IGEP boards is really interesting, just want to look deeper :)

Right. To play the thought exercise out a bit farther, if all of the detection methods for Beagleboard would _not_ cause an OVERO COM to be identified as a Beagle, we could move on to trying to see what rev overo we're on, or just assume it's that if all else fails. Is anything like that possible with these IGEP boards?

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

And to be clear over on this part, if we can tell at run time (or normal build time even, without directly passing MACH_TYPE=..) we should set that then instead of SYS_EXTRA_OPTIONS.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160921/52fea954/attachment.sig>
author
#12 lore raw

PATCH 2/3 igep00x0: consolidate defconfigs

Quoted 34 lines · Tom Rini
Quoted 33 lines · Enric Balletbo Serra

2016-09-21 14:51 GMT+02:00 Tom Rini <[email protected]>:

Quoted 31 lines · Enric Balletbo Serra
Quoted 22 lines

Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 11 lines · Tom Rini
Quoted 2 lines · Ladislav Michl
Quoted 1 line · Tom Rini

[snip]

Quoted 7 lines
Quoted 6 lines
Quoted 1 line

But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with daughter boards specific patches on top of it. Enric is concerned not to break that support, so I'm trying to keep it.

Quoted 7 lines
Quoted 2 lines

OK, if you're still supporting stuff that old then yes, it makes sense. And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards (0020, 0030 and 0032) at runtime, but never get an answer. Of course I'd like to see one U-Boot binary to rule them all, but I'm out of clue there. Few people added to Cc...

Quoted 5 lines

There is no way to differentiate those boards at runtime, those boards are completely different platforms that share same processor, like BeagleBoard or OMAP3 Overos . For me what you're trying to do is join different platforms with the same processor, so why not join BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Note that the different beagleboard used GPIOs to tell which platform is which :)

Quoted 6 lines
Quoted 6 lines

Yes, but if I'm not mistaken you have different GPIOs for different hardware revisions of Beagleboard. For IGEPv2 this is also true, you have different GPIOs for different hardware revisions of IGEPv2. But we're talking about join two completely different boards, i.e join IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to join Beagleboard with OMAP3 OVERO COM.

Well, on igep platform MACH_TYPE is currently used for:
- mux configuration (with IGEP COM PROTON strangely left out)
- status LED configuration
I wouldn't say these are completely different boards, at lest from software perspective.

Quoted 8 lines
Quoted 2 lines

OTOH I think the Ladis work trying to join the IGEP boards is really interesting, just want to look deeper :)

Right. To play the thought exercise out a bit farther, if all of the detection methods for Beagleboard would _not_ cause an OVERO COM to be identified as a Beagle, we could move on to trying to see what rev overo we're on, or just assume it's that if all else fails. Is anything like that possible with these IGEP boards?

I certainly didn't mean any board detection method hardware designer had in mind while drawing schemantics, but more likely something like this:
IGEPv2 is using GPIO_94 to drive WIFI_PD_n and there's 100K pullup, so setting this pin as input and reading its value could give some clue. Now question is if there's such a combination of gpios used over this board family, which provides reliable detection method. Unfortunately, I have only IGEPv2 and public schemantics is available only for this board.

Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

Another approach might be to configure U-Boot using FDT and translate that information into MACH_TYPE and kernel command line to support non-device tree enabled kernels.

And to be clear over on this part, if we can tell at run time (or normal build time even, without directly passing MACH_TYPE=..) we should set that then instead of SYS_EXTRA_OPTIONS.

ladis

author
#13 lore raw

PATCH 3/3 igep00x0: add Hynix timings

In reply to Ladislav Michl

Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by Ladislav Michl <[email protected]>
---
 board/isee/igep00x0/igep00x0.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)
board/isee/igep00x0/igep00x0.c +16 -4
index 71688cc..669f3dd 100644
@@ -84,10 +84,22 @@ void get_board_mem_timings(struct board_sdrc_timings *timings)
 	int mfr, id, err = identify_nand_chip(&mfr, &id);
 
 	timings->mr = MICRON_V_MR_165;
-	if (!err && mfr == NAND_MFR_MICRON) {
-		timings->mcfg = MICRON_V_MCFG_200(256 << 20);
-		timings->ctrla = MICRON_V_ACTIMA_200;
-		timings->ctrlb = MICRON_V_ACTIMB_200;
+	if (!err) {
+		switch (mfr) {
+		case NAND_MFR_HYNIX:
+			timings->mcfg = HYNIX_V_MCFG_200(256 << 20);
+			timings->ctrla = HYNIX_V_ACTIMA_200;
+			timings->ctrlb = HYNIX_V_ACTIMB_200;
+			break;
+		case NAND_MFR_MICRON:
+			timings->mcfg = MICRON_V_MCFG_200(256 << 20);
+			timings->ctrla = MICRON_V_ACTIMA_200;
+			timings->ctrlb = MICRON_V_ACTIMB_200;
+			break;
+		default:
+			/* Should not happen... */
+			break;
+		}
 		timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
 		gpmc_cs0_flash = MTD_DEV_TYPE_NAND;
 	} else {
Signature · 1 line
2.1.4
#14 lore raw

PATCH 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

In reply to Ladislav Michl

Hi Ladis,

2016-09-20 11:04 GMT+02:00 Ladislav Michl <[email protected]>:

Quoted 57 lines

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as there's no known way to distinguish between them. Also saves few bytes as a bonus.

Signed-off-by Ladislav Michl <[email protected]>
---
 board/isee/igep00x0/igep00x0.c   | 18 ------------------
 include/configs/omap3_igep00x0.h |  5 +----
 2 files changed, 1 insertion(+), 22 deletions(-)
board/isee/igep00x0/igep00x0.c +0 -18
index 808955e..71688cc 100644
@@ -27,24 +27,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-const omap3_sysinfo sysinfo = {
-       DDR_STACKED,
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
-       "IGEPv2",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
-       "IGEP COM MODULE/ELECTRON",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
-       "IGEP COM PROTON",
-#endif
-#if defined(CONFIG_ENV_IS_IN_ONENAND)
-       "ONENAND",
-#else
-       "NAND",
-#endif
-};
-
 static const struct ns16550_platdata igep_serial = {
        .base = OMAP34XX_UART3,
        .reg_shift = 2,
include/configs/omap3_igep00x0.h +1 -5
index 1f30710..2ae9737 100644
@@ -23,11 +23,8 @@
 #undef CONFIG_SPL_TEXT_BASE
 #define CONFIG_SPL_TEXT_BASE           0x40200000
 
-/*
- * Display CPU and Board information
- */
+/* Display CPU information */
 #define CONFIG_DISPLAY_CPUINFO         1
-#define CONFIG_DISPLAY_BOARDINFO       1
 
 #define CONFIG_MISC_INIT_R
 
--
Quoted 2 lines

2.1.4

I must NACK for now these series, meanwhile I don't find time to look at this deeply. I think this will break lots of things. For example, will this u-boot boot a non-device tree based kernel without breaking things? I don't think so, It's right that non-device tree kernels are old but these are still used in lots of IGEP boards and I don't want to break this, for now.

Please give me some time to look at this and think in all the use cases.

Thanks,
Enric.

author
#15 lore raw

PATCH 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

Hi Enric,

Quoted 10 lines · Enric Balletbo Serra

Hi Ladis,

I must NACK for now these series, meanwhile I don't find time to look at this deeply. I think this will break lots of things. For example, will this u-boot boot a non-device tree based kernel without breaking things? I don't think so, It's right that non-device tree kernels are old but these are still used in lots of IGEP boards and I don't want to break this, for now.

Please give me some time to look at this and think in all the use cases.

I'm sorry for screwing up MACH_TYPE, here's an updated version. I haven't tested with non-device tree kernels, but I can't see how these patches could break it. Please let me know, if you find any other objections.

Best regards,
ladis

8< -----------------------

author
#16 lore raw

PATCH 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

In reply to Enric Balletbo Serra

Hi Enric,

On Tue, Sep 20, 2016 at 05:41:02PM +0200, Enric Balletbo Serra wrote:
[snip]

Quoted 8 lines

I must NACK for now these series, meanwhile I don't find time to look at this deeply. I think this will break lots of things. For example, will this u-boot boot a non-device tree based kernel without breaking things? I don't think so, It's right that non-device tree kernels are old but these are still used in lots of IGEP boards and I don't want to break this, for now.

Please give me some time to look at this and think in all the use cases.

Any chance you'll find time to look at this? I'm sending updated patch serie as a reply to this email. I do not think it breaks anything and I'll provide fix if you prove me wrong. Please note, that without "igep00x0: add Hynix timings" patch some boards are unable to boot. My bad, of course, as I hadn't all board variants on my table at the time writing runtime flash detection support.

Thank you,
ladis

author
#17 lore raw

PATCH v2 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus.

Signed-off-by Ladislav Michl <[email protected]>

---
Changes in v2:
- update to current git (uses Kconfig)

board/isee/igep00x0/igep00x0.c +0 -18
index 808955e..71688cc 100644
@@ -27,24 +27,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-const omap3_sysinfo sysinfo = {
-	DDR_STACKED,
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
-	"IGEPv2",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
-	"IGEP COM MODULE/ELECTRON",
-#endif
-#if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
-	"IGEP COM PROTON",
-#endif
-#if defined(CONFIG_ENV_IS_IN_ONENAND)
-	"ONENAND",
-#else
-	"NAND",
-#endif
-};
-
 static const struct ns16550_platdata igep_serial = {
 	.base = OMAP34XX_UART3,
 	.reg_shift = 2,
configs/igep0020_defconfig +1 -0
index 9c247d7..c25b6b8 100644
@@ -7,6 +7,7 @@ CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
configs/igep0030_defconfig +1 -0
index 1312ddb..75f731d 100644
@@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
configs/igep0032_defconfig +1 -0
index 37e46b0..1819995 100644
@@ -6,6 +6,7 @@ CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_ONENAND_SUPPORT=y
Signature · 1 line
2.1.4

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#19 lore raw

PATCH v2 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

Quoted 8 lines · Javier Martinez Canillas

Hello Ladis,

Quoted 5 lines · Ladislav Michl

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus.

Quoted 7 lines
Quoted 2 lines
Signed-off-by Ladislav Michl <[email protected]>

---

I tried to test your patches on latest u-boot master (sha-1 dd93a8e9e688) but my IGEPv2 board fails to boot and prints in an infinite loop following:

"ecc unrecoverable error"

This comes from SPL, right? That would imply you boot from NAND...

Quoted 5 lines

This is not related to your patches though, since I've the same issue without your patches applied.

Did you see this issue? u-boot works with previous v2016.09 release so this is a newly introduced regression.

No, otherwise I would fix that. Care to send complete boot log if there is any?

Quoted 2 lines

Unfortunately I don't have time to dig deeper on this but I may give a try next week.

Thank you,
ladis

#20 lore raw

PATCH v2 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

Hello Ladis,

Quoted 19 lines · Ladislav Michl
Quoted 8 lines · Javier Martinez Canillas

Hello Ladis,

Quoted 5 lines · Ladislav Michl

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus.

Quoted 7 lines
Quoted 2 lines
Signed-off-by Ladislav Michl <[email protected]>

---

I tried to test your patches on latest u-boot master (sha-1 dd93a8e9e688) but my IGEPv2 board fails to boot and prints in an infinite loop following:

"ecc unrecoverable error"

This comes from SPL, right? That would imply you boot from NAND...

Quoted 9 lines
Quoted 5 lines

This is not related to your patches though, since I've the same issue without your patches applied.

Did you see this issue? u-boot works with previous v2016.09 release so this is a newly introduced regression.

No, otherwise I would fix that. Care to send complete boot log if there is any?

As talked on irc, this is because I don't have an UBI partition on my NAND. I've just commented the error messages for now to be able to boot since this is an unrelated issue.

Quoted 5 lines
Quoted 2 lines

Unfortunately I don't have time to dig deeper on this but I may give a try next week.

Thank you,
ladis

Best regards,
Javier

#21 lore raw

PATCH v2 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

In reply to Ladislav Michl

Hello Ladis,

Quoted 7 lines · Ladislav Michl

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus.

Signed-off-by Ladislav Michl <[email protected]>

---

Patch looks good to me.

Reviewed-by Javier Martinez Canillas <[email protected]>

I've also tested on an IGEPv2 board:

Tested-by Javier Martinez Canillas <[email protected]>

Best regards,
Javier

#22 lore raw

PATCH v2 1/3 igep00x0: disable CONFIG_DISPLAY_BOARDINFO

In reply to Ladislav Michl
Quoted 8 lines · Ladislav Michl

As a single U-Boot binary can now run on various board modifications, drop CONFIG_DISPLAY_BOARDINFO as it prints flash memory information too early to give us chance to easily detect it. Also saves few bytes as a bonus.

Signed-off-by Ladislav Michl <[email protected]>
Reviewed-by Javier Martinez Canillas <[email protected]>
Tested-by Javier Martinez Canillas <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161113/954afc07/attachment.sig>
author
#23 lore raw

PATCH v2 2/3 igep00x0: consolidate defconfigs

In reply to Ladislav Michl

Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS. Drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>

---
Changes in v2:
- fix screwup caused by mismerge
- update to current git

configs/igep0030_defconfig +3 -1
index 75f731d..edc7520 100644
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030"
+CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y

@@ -31,5 +32,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
configs/igep0030_nand_defconfig deleted +0 -34
deleted file mode 100644
index dda1a7b..0000000
@@ -1,34 +0,0 @@
-CONFIG_ARM=y
-CONFIG_OMAP34XX=y
-# CONFIG_SPL_EXT_SUPPORT is not set
-CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND"
-CONFIG_SYS_CONSOLE_IS_IN_ENV=y
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_VERSION_VARIABLE=y
-CONFIG_SPL=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMLS is not set
-CONFIG_CMD_ASKENV=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_CMD_UBI=y
-CONFIG_SYS_NS16550=y
-CONFIG_OF_LIBFDT=y
configs/igep0032_defconfig +2 -1
index 1819995..81d05d4 100644
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032"
+CONFIG_BOOTDELAY=3
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
Signature · 1 line
2.1.4
#25 lore raw

PATCH v2 2/3 igep00x0: consolidate defconfigs

In reply to Ladislav Michl
Quoted 5 lines · Ladislav Michl

Defconfigs should remain the same except CONFIG_SYS_EXTRA_OPTIONS. Drop NAND specific defconfig as flash type is runtime detected.

Signed-off-by Ladislav Michl <[email protected]>
Reviewed-by Javier Martinez Canillas <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161113/d17eba5f/attachment.sig>
author
#26 lore raw

PATCH v2 3/3 igep00x0: add Hynix timings

In reply to Ladislav Michl

Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by Ladislav Michl <[email protected]>

---
Changes in v2:
- None

board/isee/igep00x0/igep00x0.c +16 -4
index 71688cc..669f3dd 100644
@@ -84,10 +84,22 @@ void get_board_mem_timings(struct board_sdrc_timings *timings)
 	int mfr, id, err = identify_nand_chip(&mfr, &id);
 
 	timings->mr = MICRON_V_MR_165;
-	if (!err && mfr == NAND_MFR_MICRON) {
-		timings->mcfg = MICRON_V_MCFG_200(256 << 20);
-		timings->ctrla = MICRON_V_ACTIMA_200;
-		timings->ctrlb = MICRON_V_ACTIMB_200;
+	if (!err) {
+		switch (mfr) {
+		case NAND_MFR_HYNIX:
+			timings->mcfg = HYNIX_V_MCFG_200(256 << 20);
+			timings->ctrla = HYNIX_V_ACTIMA_200;
+			timings->ctrlb = HYNIX_V_ACTIMB_200;
+			break;
+		case NAND_MFR_MICRON:
+			timings->mcfg = MICRON_V_MCFG_200(256 << 20);
+			timings->ctrla = MICRON_V_ACTIMA_200;
+			timings->ctrlb = MICRON_V_ACTIMB_200;
+			break;
+		default:
+			/* Should not happen... */
+			break;
+		}
 		timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
 		gpmc_cs0_flash = MTD_DEV_TYPE_NAND;
 	} else {
Signature · 1 line
2.1.4
#27 lore raw

PATCH v2 3/3 igep00x0: add Hynix timings

Hello Ladis,

Quoted 5 lines · Ladislav Michl

Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by Ladislav Michl <[email protected]>

---

Reviewed-by Javier Martinez Canillas <[email protected]>

I don't have an IGEPv2 with Hynix to test, but everything is working correctly on my IGEPv2 board with a Micron NAND.

Tested-by Javier Martinez Canillas <[email protected]>

Best regards,
Javier

#28 lore raw

PATCH v2 3/3 igep00x0: add Hynix timings

In reply to Ladislav Michl
Quoted 6 lines · Ladislav Michl

Tested on IGEPv2 with Micron MT29F4G16ABBDA3W and
Hynix H27S4G6F2DKA-BM

Signed-off-by Ladislav Michl <[email protected]>
Reviewed-by Javier Martinez Canillas <[email protected]>
Tested-by Javier Martinez Canillas <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161113/ed028b31/attachment.sig>