Skip to contentSkip to conversation

configs: new defconfig for TI am335x-evm

PATCH New Lothar Felten 3 participants 13 messages Aug 15, 2016 – Sep 23, 2016

lore
Share & tools
lore

Lothar Felten

author
#0 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

This patch adds a target config for the ti am335x-evm based on the AM335x CPU. It also supports the beaglebone and beagleboneblack.
Device tree blobs for am335x-evm, am335x-evmsk, am335x-bone, am335x-boneblack will be built and a sd card image is created with a post-image script. The kernel and driver versions match the ti-processor-sdk 02.00.00.00. Patches allow the use of old AM335x evm revisions (1 bit sd card) and JTAG debugging.

Kernel JTAG patch:
By default the kernel will disable the JTAG clock, access via the JTAG port will not work after the kernel booted. The AM335x-evm has a JTAG header fitted, this patch keeps the JTAG clock alive.

Uboot SD card patch:
Early AM335x-evm boards can only use 1 bit communication to the SD card, on newer board revisions this might be fixed.
Forcing 1 bit communication slows down the communication but will work regardless if the SD card is attached via 1 or 4 bits.
If the board has a working 4 bit SD card interface, this patch can be removed, this will speed up the access.

Signed-off-by Lothar Felten <[email protected]>
---
 board/ti/am335x-evm/genimage.cfg                   | 32 +++++++++++++
 .../0001-keep-jtag-clock-alive-for-debugger.patch  | 16 +++++++
 .../uboot/0001-mmc-force-1bit-bus-width.patch      | 35 +++++++++++++++
 board/ti/am335x-evm/post-image.sh                  | 22 +++++++++
 board/ti/am335x-evm/readme.txt                     | 52 ++++++++++++++++++++++
 board/ti/am335x-evm/uEnv.txt                       |  3 ++
 configs/am335x-evm_defconfig                       | 25 +++++++++++
 7 files changed, 185 insertions(+)
 create mode 100644 board/ti/am335x-evm/genimage.cfg
 create mode 100644 board/ti/am335x-evm/patches/linux/0001-keep-jtag-clock-alive-for-debugger.patch
 create mode 100644 board/ti/am335x-evm/patches/uboot/0001-mmc-force-1bit-bus-width.patch
 create mode 100755 board/ti/am335x-evm/post-image.sh
 create mode 100644 board/ti/am335x-evm/readme.txt
 create mode 100644 board/ti/am335x-evm/uEnv.txt
 create mode 100644 configs/am335x-evm_defconfig
board/ti/am335x-evm/genimage.cfg new file +32 -0
new file mode 100644
index 0000000..c9de722
@@ -0,0 +1,32 @@
+image boot.vfat {
+	vfat {
+		files = {
+			"MLO",
+			"u-boot.img",
+			"zImage",
+			"uEnv.txt",
+			"am335x-evm.dtb",
+			"am335x-evmsk.dtb",
+			"am335x-bone.dtb",
+			"am335x-boneblack.dtb",
+		}
+	}
+	size = 16M
+}
+
+image sdcard.img {
+	hdimage {
+	}
+
+	partition u-boot {
+		partition-type = 0xC
+		bootable = "true"
+                image = "boot.vfat"
+	}
+
+	partition rootfs {
+		partition-type = 0x83
+		image = "rootfs.ext2"
+		size = 240M
+	}
+}
board/ti/am335x-evm/patches/linux/0001-keep-jtag-clock-alive-for-debugger.patch new file +16 -0
new file mode 100644
index 0000000..324915e
@@ -0,0 +1,16 @@
+This patch keeps the debugSS clock alive, it clock the JTAG macro and enables
+access to the SoC via JTAG after the kernel booted.
+
+Signed-off-by: Lothar Felten <[email protected]>
+---
+diff -Naur linux-orig/arch/arm/mach-omap2/omap_hwmod_33xx_data.c linux-52c4aa7cdb93d61f8008f380135beaf7b8fa6593/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+--- linux-orig/arch/arm/mach-omap2/omap_hwmod_33xx_data.c	2015-10-02 17:30:56.000000000 +0200
++++ linux-52c4aa7cdb93d61f8008f380135beaf7b8fa6593/arch/arm/mach-omap2/omap_hwmod_33xx_data.c	2016-08-15 11:28:55.017617612 +0200
+@@ -208,6 +208,7 @@
+ 	.name		= "debugss",
+ 	.class		= &am33xx_debugss_hwmod_class,
+ 	.clkdm_name	= "l3_aon_clkdm",
++	.flags		= (HWMOD_INIT_NO_IDLE|HWMOD_INIT_NO_RESET), /* keep debugSS clock alive for JTAG */
+ 	.main_clk	= "trace_clk_div_ck",
+ 	.prcm		= {
+ 		.omap4	= {
board/ti/am335x-evm/patches/uboot/0001-mmc-force-1bit-bus-width.patch new file +35 -0
new file mode 100644
index 0000000..c47500b
@@ -0,0 +1,35 @@
+This patch forces tge MMC interface to work in 1-bit-mode.
+Early AM335x-evm boards can only use 1 bit communication to the SD card, on
+newer board revisions this might be fixed.
+
+Signed-off-by: Lothar Felten <[email protected]>
+---
+diff -Naur a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
+--- a/drivers/mmc/mmc.c	2016-05-16 16:40:32.000000000 +0200
++++ b/drivers/mmc/mmc.c	2016-07-11 13:23:13.235880737 +0200
+@@ -1351,25 +1351,6 @@
+ 	mmc->card_caps &= mmc->cfg->host_caps;
+ 
+ 	if (IS_SD(mmc)) {
+-		if (mmc->card_caps & MMC_MODE_4BIT) {
+-			cmd.cmdidx = MMC_CMD_APP_CMD;
+-			cmd.resp_type = MMC_RSP_R1;
+-			cmd.cmdarg = mmc->rca << 16;
+-
+-			err = mmc_send_cmd(mmc, &cmd, NULL);
+-			if (err)
+-				return err;
+-
+-			cmd.cmdidx = SD_CMD_APP_SET_BUS_WIDTH;
+-			cmd.resp_type = MMC_RSP_R1;
+-			cmd.cmdarg = 2;
+-			err = mmc_send_cmd(mmc, &cmd, NULL);
+-			if (err)
+-				return err;
+-
+-			mmc_set_bus_width(mmc, 4);
+-		}
+-
+ 		if (mmc->card_caps & MMC_MODE_HS)
+ 			mmc->tran_speed = 50000000;
+ 		else
board/ti/am335x-evm/post-image.sh new file +22 -0
new file mode 100755
index 0000000..6b16f40
@@ -0,0 +1,22 @@
+#!/bin/sh
+# post-image.sh for ti am335x-evm
+# based on post-image from beagleboard
+# 2014, Marcin Jabrzyk <[email protected]>
+# 2016, Lothar Felten <[email protected]>
+
+BOARD_DIR="$(dirname $0)"
+
+# copy the uEnv.txt to the output/images directory
+cp board/ti/am335x-evm/uEnv.txt $BINARIES_DIR/uEnv.txt
+
+GENIMAGE_CFG="${BOARD_DIR}/genimage.cfg"
+GENIMAGE_TMP="${BUILD_DIR}/genimage.tmp"
+
+rm -rf "${GENIMAGE_TMP}"
+
+genimage \
+    --rootpath "${TARGET_DIR}" \
+    --tmppath "${GENIMAGE_TMP}" \
+    --inputpath "${BINARIES_DIR}" \
+    --outputpath "${BINARIES_DIR}" \
+    --config "${GENIMAGE_CFG}"
board/ti/am335x-evm/readme.txt new file +52 -0

52 lines not on this page · raw message

board/ti/am335x-evm/uEnv.txt new file +3 -0
new file mode 100644
index 0000000..e09fff5
@@ -0,0 +1,3 @@
+bootpart=0:1
+bootdir=
+uenvcmd=run loadimage;run loadramdisk;run findfdt;run loadfdt;run ramboot
configs/am335x-evm_defconfig new file +25 -0
new file mode 100644
index 0000000..c834b17
@@ -0,0 +1,25 @@
+BR2_arm=y
+BR2_cortex_a8=y
+BR2_GLOBAL_PATCH_DIR="board/ti/am335x-evm/patches"
+BR2_KERNEL_HEADERS_4_1=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/ti/am335x-evm/post-image.sh"
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_GIT=y
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://git.ti.com/processor-sdk/processor-sdk-linux.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="52c4aa7cdb93d61f8008f380135beaf7b8fa6593"
+BR2_LINUX_KERNEL_DEFCONFIG="omap2plus"
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack am335x-evmsk"
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.05"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am335x_evm"
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="MLO"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 2 lines · Lothar Felten

This patch adds a target config for the ti am335x-evm based on the AM335x CPU. It also supports the beaglebone and beagleboneblack.

How can it support also the BeagleBone and BeagleBoneBlack when the U-Boot is configured with:

+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am335x_evm"

I.e, isn't U-Boot consequently only working on the arm335x_evm platform? Or is the am335x_evm U-Boot configuration also usable for BeagleBone/BeagleBoneBlack?

It seems that it's the case thanks to:

CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"

in the U-Boot configuration. Can you confirm?

If that's the case, then is the name of the defconfig really properly chosen? Should we remove beaglebone_defconfig in favor of a common defconfig for all am335x configurations?

I'd say, either we name the defconfig am335x_evm_defconfig, and it should support only this board, or we name it am335x_defconfig and it supports multiple boards and replaces other AM335x defconfigs we already have.

Quoted 7 lines

Uboot SD card patch:
Early AM335x-evm boards can only use 1 bit communication to the SD card, on newer board revisions this might be fixed.
Forcing 1 bit communication slows down the communication but will work regardless if the SD card is attached via 1 or 4 bits.
If the board has a working 4 bit SD card interface, this patch can be removed, this will speed up the access.

Do you still have those early AM335x EVM boards? Are they widespread? I'm wondering if it really makes sense to have this patch.

board/ti/am335x-evm/readme.txt line 17

Quoted 5 lines
board/ti/am335x-evm/readme.txt new file +5 -0
+How to build it
+===============
+
+Select the default configuration for the am335x-evm target:
+$ make am335x-evm_defconfig

The defconfig name should be using _ as separator, not -.

configs/am335x-evm_defconfig line 4

Quoted 10 lines
configs/am335x-evm_defconfig new file +4 -0
new file mode 100644
index 0000000..c834b17
@@ -0,0 +1,25 @@
+BR2_arm=y
+BR2_cortex_a8=y
+BR2_GLOBAL_PATCH_DIR="board/ti/am335x-evm/patches"
+BR2_KERNEL_HEADERS_4_1=y

Use "same headers as the kernel sources" option please.

configs/am335x-evm_defconfig line 5

Quoted 1 line
configs/am335x-evm_defconfig new file +1 -0
+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"

Does this really work for the BeagleBone, which uses ttyO2 if I remember correctly? Maybe another reason to have a defconfig that supports just the am335x_evm.

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#2 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 2 lines · Lothar Felten

This patch adds a target config for the ti am335x-evm based on the AM335x CPU. It also supports the beaglebone and beagleboneblack.

Quoted 8 lines

How can it support also the BeagleBone and BeagleBoneBlack when the U-Boot is configured with:

+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am335x_evm"

I.e, isn't U-Boot consequently only working on the arm335x_evm platform? Or is the am335x_evm U-Boot configuration also usable for BeagleBone/BeagleBoneBlack?

I believe so, yes. It afaik detects the board variant based on the content of an i2c eeprom.

Quoted 6 lines

It seems that it's the case thanks to:

CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"

in the U-Boot configuration. Can you confirm?

Quoted 8 lines

If that's the case, then is the name of the defconfig really properly chosen? Should we remove beaglebone_defconfig in favor of a common defconfig for all am335x configurations?

I'd say, either we name the defconfig am335x_evm_defconfig, and it should support only this board, or we name it am335x_defconfig and it supports multiple boards and replaces other AM335x defconfigs we already have.

Well, it is only for the ti/circuitco boards, not any other boards with a am335x.

I still think naming the defconfig beaglebone_defconfig makes it easier to find for newcomers, even though it could also be used on the TI evm. People are also much more likely to have one of the beaglebone variants than the evm.

Signature · 1 line
Bye, Peter Korsgaard
#3 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 8 lines · Peter Korsgaard
Quoted 5 lines

+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am335x_evm"

I.e, isn't U-Boot consequently only working on the arm335x_evm platform? Or is the am335x_evm U-Boot configuration also usable for BeagleBone/BeagleBoneBlack?

I believe so, yes. It afaik detects the board variant based on the content of an i2c eeprom.

Hum, OK.

Quoted 15 lines
Quoted 6 lines

It seems that it's the case thanks to:

CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"

in the U-Boot configuration. Can you confirm?

Quoted 8 lines

If that's the case, then is the name of the defconfig really properly chosen? Should we remove beaglebone_defconfig in favor of a common defconfig for all am335x configurations?

I'd say, either we name the defconfig am335x_evm_defconfig, and it should support only this board, or we name it am335x_defconfig and it supports multiple boards and replaces other AM335x defconfigs we already have.

Quoted 7 lines

Well, it is only for the ti/circuitco boards, not any other boards with a am335x.

I still think naming the defconfig beaglebone_defconfig makes it easier to find for newcomers, even though it could also be used on the TI evm. People are also much more likely to have one of the beaglebone variants than the evm.

So maybe it's easier to have separate beaglebone_defconfig (for just the beaglebone) and am335x_evm_defconfig (for just the EVM), without trying to have a defconfig that handles multiple boards.

What do you think?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#4 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 10 lines
Quoted 4 lines

I still think naming the defconfig beaglebone_defconfig makes it easier to find for newcomers, even though it could also be used on the TI evm. People are also much more likely to have one of the beaglebone variants than the evm.

So maybe it's easier to have separate beaglebone_defconfig (for just the beaglebone) and am335x_evm_defconfig (for just the EVM), without trying to have a defconfig that handles multiple boards.

What do you think?

If they are not identical, then yes. Are these minor differences critical enough that it makes sense to maintain two defconfigs?

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
#5 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 8 lines · Peter Korsgaard
Quoted 5 lines

So maybe it's easier to have separate beaglebone_defconfig (for just the beaglebone) and am335x_evm_defconfig (for just the EVM), without trying to have a defconfig that handles multiple boards.

What do you think?

If they are not identical, then yes. Are these minor differences critical enough that it makes sense to maintain two defconfigs?

How would you name this common configuration then?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#6 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 4 lines · Peter Korsgaard
Quoted 3 lines

So maybe it's easier to have separate beaglebone_defconfig (for just the beaglebone) and am335x_evm_defconfig (for just the EVM), without trying to have a defconfig that handles multiple boards.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

What do you think?

If they are not identical, then yes. Are these minor differences critical enough that it makes sense to maintain two defconfigs?

How would you name this common configuration then?

I would just call it beaglebone, and mention in the readme what boards it works on.

Newcomers are much more likely to have one of the beaglebone boards than an evm, so naming it like that imho makes sense.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
#7 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 5 lines · Peter Korsgaard

I would just call it beaglebone, and mention in the readme what boards it works on.

Newcomers are much more likely to have one of the beaglebone boards than an evm, so naming it like that imho makes sense.

OK. So in the end, we're just asking Lothar to update the existing beaglebone_defconfig configuration to:

1/ Use more recent versions of the different components

2/ Support other AM335X boards in addition to the Beaglebone

Is that what you're thinking about?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#8 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 5 lines · Peter Korsgaard

I would just call it beaglebone, and mention in the readme what boards it works on.

Newcomers are much more likely to have one of the beaglebone boards than an evm, so naming it like that imho makes sense.

Quoted 8 lines

OK. So in the end, we're just asking Lothar to update the existing beaglebone_defconfig configuration to:

1/ Use more recent versions of the different components

2/ Support other AM335X boards in addition to the Beaglebone

Is that what you're thinking about?

Yes, that imho makes sense.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
#9 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

In reply to Peter Korsgaard

Hello,

Quoted 7 lines · Peter Korsgaard
Quoted 1 line

How would you name this common configuration then?

I would just call it beaglebone, and mention in the readme what boards it works on.

Newcomers are much more likely to have one of the beaglebone boards than an evm, so naming it like that imho makes sense.

OK, fine with me.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
author
#10 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 9 lines · Thomas Petazzoni

Hello,

Quoted 5 lines · Peter Korsgaard
Quoted 1 line

How would you name this common configuration then?

I would just call it beaglebone, and mention in the readme what boards it works on.

Quoted 7 lines
Quoted 2 lines

Newcomers are much more likely to have one of the beaglebone boards than an evm, so naming it like that imho makes sense.

OK, fine with me.

Thomas

I changed the patches, they now update the current beaglebone, the defconfigs will be: beaglebone_defconfig and beaglebone_qt_defconfig. The readme.txt lists the supported targets.

Quoted 10 lines
Quoted 7 lines

Uboot SD card patch:
Early AM335x-evm boards can only use 1 bit communication to the SD card, on newer board revisions this might be fixed.
Forcing 1 bit communication slows down the communication but will work regardless if the SD card is attached via 1 or 4 bits.
If the board has a working 4 bit SD card interface, this patch can be removed, this will speed up the access.

Do you still have those early AM335x EVM boards? Are they widespread? I'm wondering if it really makes sense to have this patch.

I've only use two EVMs and they both have the issue, I'm not sure that it ever got fixed. Any board will run in 1 bit mode, but some evms won't run in 4 bit mode, so I think that's a safe choice. Anyway, it applies to the uboot only.

Quoted 3 lines
Quoted 1 line

+BR2_KERNEL_HEADERS_4_1=y

Use "same headers as the kernel sources" option please.

ok

Quoted 5 lines
Quoted 1 line

+BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"

Does this really work for the BeagleBone, which uses ttyO2 if I remember correctly? Maybe another reason to have a defconfig that supports just the am335x_evm.

The beaglebone (ttyO0 on USB) beagleboneblack (ttyO0 on pinheader) and the evm (sub d 9 pin) all use ttyO0

Lothar

#11 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

Hello,

Quoted 3 lines · Lothar Felten

I changed the patches, they now update the current beaglebone, the defconfigs will be: beaglebone_defconfig and beaglebone_qt_defconfig. The readme.txt lists the supported targets.

Sounds good.

Quoted 7 lines
Quoted 2 lines

Do you still have those early AM335x EVM boards? Are they widespread? I'm wondering if it really makes sense to have this patch.

I've only use two EVMs and they both have the issue, I'm not sure that it ever got fixed. Any board will run in 1 bit mode, but some evms won't run in 4 bit mode, so I think that's a safe choice. Anyway, it applies to the uboot only.

OK, let's keep this then. What worries me is that the kind of patch that has never any chance of being removed from Buildroot. I would have preferred a solution that could potentially be accepted upstream.

Quoted 6 lines
Quoted 3 lines

Does this really work for the BeagleBone, which uses ttyO2 if I remember correctly? Maybe another reason to have a defconfig that supports just the am335x_evm.

The beaglebone (ttyO0 on USB) beagleboneblack (ttyO0 on pinheader) and the evm (sub d 9 pin) all use ttyO0

OK, my bad. I was probably confusing with the beagleboard where I think it was the third serial port (ttyO2). So everything is fine.

Thanks a lot!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#12 lore raw

PATCH 1/1 configs: new defconfig for TI am335x-evm

In reply to Lothar Felten
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Lothar" == Lothar Felten <[email protected]> writes:

Hi,

Quoted 3 lines

I changed the patches, they now update the current beaglebone, the defconfigs will be: beaglebone_defconfig and beaglebone_qt_defconfig. The readme.txt lists the supported targets.

Ok, great!

Quoted 8 lines
Quoted 8 lines
Quoted 7 lines

Uboot SD card patch:
Early AM335x-evm boards can only use 1 bit communication to the SD card, on newer board revisions this might be fixed.
Forcing 1 bit communication slows down the communication but will work regardless if the SD card is attached via 1 or 4 bits.
If the board has a working 4 bit SD card interface, this patch can be removed, this will speed up the access.

Quoted 7 lines
Quoted 2 lines

Do you still have those early AM335x EVM boards? Are they widespread? I'm wondering if it really makes sense to have this patch.

I've only use two EVMs and they both have the issue, I'm not sure that it ever got fixed. Any board will run in 1 bit mode, but some evms won't run in 4 bit mode, so I think that's a safe choice. Anyway, it applies to the uboot only.

What is the upstream status of this? Have you discussed it on the u-boot list? Right now, this is a hack that isn't suitable for upstream, but how about tweaking omap_hsmmc host_cap if we are running on the evm?

As it stands, the beaglebone boards are also forced into 1bit mode even though they don't have the problem.

Quoted 6 lines
Quoted 3 lines

Does this really work for the BeagleBone, which uses ttyO2 if I remember correctly? Maybe another reason to have a defconfig that supports just the am335x_evm.

The beaglebone (ttyO0 on USB) beagleboneblack (ttyO0 on pinheader) and the evm (sub d 9 pin) all use ttyO0

Ok, great!

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard