Message ID | 1471261882-5640-1-git-send-email-lothar.felten@gmail.com |
---|---|
State | Changes Requested |
Headers | show |
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" == 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.
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" == 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?
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" == 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.
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" == 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.
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
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
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
>>>>> "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!
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
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