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

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

[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.
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 <lothar.felten@gmail.com>
---
 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

diff --git a/board/ti/am335x-evm/genimage.cfg b/board/ti/am335x-evm/genimage.cfg
new file mode 100644
index 0000000..c9de722
--- /dev/null
+++ b/board/ti/am335x-evm/genimage.cfg
@@ -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
+	}
+}
diff --git a/board/ti/am335x-evm/patches/linux/0001-keep-jtag-clock-alive-for-debugger.patch b/board/ti/am335x-evm/patches/linux/0001-keep-jtag-clock-alive-for-debugger.patch
new file mode 100644
index 0000000..324915e
--- /dev/null
+++ b/board/ti/am335x-evm/patches/linux/0001-keep-jtag-clock-alive-for-debugger.patch
@@ -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 <lothar.felten@gmail.com>
+---
+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	= {
diff --git a/board/ti/am335x-evm/patches/uboot/0001-mmc-force-1bit-bus-width.patch b/board/ti/am335x-evm/patches/uboot/0001-mmc-force-1bit-bus-width.patch
new file mode 100644
index 0000000..c47500b
--- /dev/null
+++ b/board/ti/am335x-evm/patches/uboot/0001-mmc-force-1bit-bus-width.patch
@@ -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 <lothar.felten@gmail.com>
+---
+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
diff --git a/board/ti/am335x-evm/post-image.sh b/board/ti/am335x-evm/post-image.sh
new file mode 100755
index 0000000..6b16f40
--- /dev/null
+++ b/board/ti/am335x-evm/post-image.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+# post-image.sh for ti am335x-evm
+# based on post-image from beagleboard
+# 2014, Marcin Jabrzyk <marcin.jabrzyk@gmail.com>
+# 2016, Lothar Felten <lothar.felten@gmail.com>
+
+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}"
diff --git a/board/ti/am335x-evm/readme.txt b/board/ti/am335x-evm/readme.txt
new file mode 100644
index 0000000..d3bd424
--- /dev/null
+++ b/board/ti/am335x-evm/readme.txt
@@ -0,0 +1,52 @@
+Texas Instuments AM335x Evaluation Module (TMDXEVM3358)
+
+Description
+===========
+
+This configuration will build a complete image for the AM335x-EVM.
+
+The configuration is based on the ti-processor-sdk-02.00.00.00.
+
+Device tree blobs for the evm-sk, and beaglebone variants are built too.
+
+
+How to build it
+===============
+
+Select the default configuration for the am335x-evm target:
+$ make am335x-evm_defconfig
+
+Optional: modify the configuration:
+$ make menuconfig
+
+Build:
+$ make
+
+
+Result of the build
+===================
+output/images/
+??? am335x-boneblack.dtb
+??? am335x-bone.dtb
+??? am335x-evm.dtb
+??? am335x-evmsk.dtb
+??? boot.vfat
+??? MLO
+??? rootfs.ext2
+??? rootfs.tar
+??? sdcard.img
+??? u-boot.img
+??? uEnv.txt
+??? zImage
+
+To copy the image file to the sdcard use dd:
+dd if=output/images/sdcard.img of=/dev/XXX
+
+
+Tested hardware
+===============
+am335x-evm (rev. 1.1A)
+beagleboneblack (rev. A5A)
+beaglebone (rev. A6)
+
+2016, Lothar Felten <lothar.felten@gmail.com>
diff --git a/board/ti/am335x-evm/uEnv.txt b/board/ti/am335x-evm/uEnv.txt
new file mode 100644
index 0000000..e09fff5
--- /dev/null
+++ b/board/ti/am335x-evm/uEnv.txt
@@ -0,0 +1,3 @@
+bootpart=0:1
+bootdir=
+uenvcmd=run loadimage;run loadramdisk;run findfdt;run loadfdt;run ramboot
diff --git a/configs/am335x-evm_defconfig b/configs/am335x-evm_defconfig
new file mode 100644
index 0000000..c834b17
--- /dev/null
+++ b/configs/am335x-evm_defconfig
@@ -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
-- 
1.9.1

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

[Thomas Petazzoni]

Hello,

On Mon, 15 Aug 2016 13:51:22 +0200, Lothar Felten wrote:
> 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.

> 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.

> +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 -.

> diff --git a/configs/am335x-evm_defconfig b/configs/am335x-evm_defconfig
> new file mode 100644
> index 0000000..c834b17
> --- /dev/null
> +++ b/configs/am335x-evm_defconfig
> @@ -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.

> +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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Mon, 15 Aug 2016 13:51:22 +0200, Lothar Felten wrote:
 >> 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?

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

 > 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.

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.

-- 
Bye, Peter Korsgaard

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

[Thomas Petazzoni]

Hello,

On Wed, 21 Sep 2016 09:40:08 +0200, Peter Korsgaard wrote:

>  > +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.

>  > 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.  
> 
> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> 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?

-- 
Venlig hilsen,
Peter Korsgaard 

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

[Thomas Petazzoni]

Hello,

On Wed, 21 Sep 2016 11:01:17 +0200, Peter Korsgaard wrote:

>  > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Wed, 21 Sep 2016 11:01:17 +0200, Peter Korsgaard wrote:

 >> > 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?

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.

-- 
Venlig hilsen,
Peter Korsgaard 

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

[Thomas Petazzoni]

Hello,

On Wed, 21 Sep 2016 12:36:21 +0200, Peter Korsgaard wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Wed, 21 Sep 2016 12:36:21 +0200, Peter Korsgaard wrote:

 >> 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?

Yes, that imho makes sense.

-- 
Venlig hilsen,
Peter Korsgaard 

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

[Thomas Petazzoni]

Hello,

On Wed, 21 Sep 2016 12:36:21 +0200, Peter Korsgaard wrote:

>  > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Lothar Felten]

Hello,

On 21.09.2016 14:09, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 21 Sep 2016 12:36:21 +0200, Peter Korsgaard wrote:
>
>>  > 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
>

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.

>> 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.

>> +BR2_KERNEL_HEADERS_4_1=y
>
> Use "same headers as the kernel sources" option please.

ok

>> +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

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

[Thomas Petazzoni]

Hello,

On Fri, 23 Sep 2016 00:21:42 +0200, Lothar Felten wrote:

> 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.

> > 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.

> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Peter Korsgaard]

>>>>> "Lothar" == Lothar Felten <lothar.felten@gmail.com> writes:

Hi,

 > 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!

 >>> 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.

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.


 >> 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!

-- 
Venlig hilsen,
Peter Korsgaard