Compile a custom u-boot for a AM355X processor

Hi,
Please allow some time to look at this.

~ Judith

Hi,

1. Is TFTP boot the only boot method available? What if you try with a different boot method, does the board boot at all?

2. Are you building with Processor SDK? Does the newly built images work on any board?

3. You hint it is custom board, can you clarify if true?

~ Judith

Hello Judith and thank you for your feedback.

I'm not expert with boot-loaders in general nor u-boot in particular. I will try to explain as much as I understand to hopefully you can provide useful support. Please, if you need more information, let me know. 

Before answering your questions, I want to explain some useful background:

We have a working u-boot 2015.10 compiled in 2016. This one: U-Boot 2015.10 (Jun 14 2016 - 16:09:45 +0200)

Unfortunately, we don't have the customized source code used to build this working u-boot available. 

Inside the first /dev/mmcblk0 device, there is a /dev/mmcblk0p1 partition formated with "vfat". After mounting, we can find "MLO" and "u-boot.img" files.

I don't know details about the exact procedure the CPU follows to boot the board. But when we switch-on the board, this is the u-boot that runs first on serial console. If we remove files inside /dev/mmcblk0p1 partition, or replace them by custom-compiled files, the board becomes completely bricked.

So, now I can answer your questions, hopefully now will be more easy to understand:

1) To avoid bricking the board, we use PXE boot process as explained in previous post (using DHCP and TFTP servers) as a second/alternative method to boot the board. This boot process works fine using u-boot.img and u-boot-spl.bin (2015.10) to boot the board. We see logs in serial console, such as  reported.

So this PXE boot process works fine and is not the problem.

Using exactly the same PXE boot process to try booting the board with u-boot custom compiled files, we don't see nothing in serial console. Nothing at all.

2) No, we don't use the Processor SDK at all. We use a cross-compiler generated using buildroot, based on gcc 10.x. We know this cross-compiler works fine, as we are building all user-space applications with it. And all user-space applications are working fine. Just for reference, this is the cross-compiler we are using:

# arm-linux-gcc --version
arm-linux-gcc.br_real (Buildroot 4.1.0-rc1-72-g23b5eb55) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This cross-compiler has been configured with this flags:

Target: arm-buildroot-linux-gnueabihf
Configured with: ./configure --prefix=/usr/local/share/broot/output/host --sysconfdir=/usr/local/share/broot/output/host/etc --enable-static --target=arm-buildroot-linux-gnueabihf --with-sysroot=/usr/local/share/broot/output/host/arm-buildroot-linux-gnueabihf/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --enable-plugins --enable-lto --with-gmp=/usr/local/share/broot/output/host --with-mpc=/usr/local/share/broot/output/host --with-mpfr=/usr/local/share/broot/output/host --with-pkgversion='Buildroot 4.1.0-rc1-72-g23b5eb55' --with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libquadmath --disable-libquadmath-support --enable-tls --enable-threads --without-isl --without-cloog --with-abi=aapcs-linux --with-cpu=cortex-a8 --with-fpu=vfpv3 --with-float=hard --with-mode=arm --enable-languages=c,c++ --with-build-time-tools=/usr/local/share/broot/output/host/arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.4.0 (Buildroot 4.1.0-rc1-72-g23b5eb55)

Do you think using this cross-compiler to build a custom u-boot could be a problem?

3) Yes, we are running a custom board based on the a AM335x Cortex A8. We are mounting custom DDR2 memory. If you need more details related with customizations, I can collect all the custom components you need to know. 

Thank you in advance!

Kind regards.

Hi Ivan,

Understood, I will look into this. Since it is an older platform, we do not have the support as K3 platforms but I will try to get the information here soon.

~ Judith

Hi Ivan,

Sorry for the delay. Can you please explain the process how you ported U-boot to custom board.

Here is a reference that can help:
- https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/08_02_00_24/exports/docs/linux/How_to_Guides/Board_Port/U-Boot.html

~ Judith

Hello Judith.

Thank you for your answer.

Yes, we followed exactly the porting guide referenced by your link.

We started with a fresh clone of your git repository:

    $ git clone git://git.ti.com/ti-u-boot/ti-u-boot.git repo

We used u-boot source code tag 08.02.00.0006 version,

    $ git checkout 08.02.00.006

as referenced here in the release notes:

https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/08_02_00_24/exports/docs/devices/AM335X/linux/Release_Specific_Release_Notes.html#release-specific-release-notes

Then we created a new custom am335x_cct_defconfig, based on am335x_evm_defconfig.

We have a custom patch to convert commit_ID 44a87e3ab85c6d64044f0b5ad677008316baad70 into our current version. Pasting here a patch longer than 3000 lines will convert this post in something completeley unreadable, but I can do that if you like. Or if you prefer, I can send it via email. Please let me know how can I provide you this patch.

Thank you!

Hi Ivan,

Sure, that can be helpful. Please sent to jm@ti.com. I will also loop in some other engineers to look into this issue.

~ Judith

Hi Ivan,

Going through the doc, why do you not remove the board detection logic? As specified here:
- Rework and remove all board-detection related code in board.c, board.h, and mux.c,

Question 1: What happens if you use old SPL and new u-boot, Linux DTB, and Linux kernel?
Question 2: Have you tried to use CCS debugger to see where we are crashing?

~ Judith

Hello Judith.

First of all, we appreciate all your support, many thanks in advance.

As first step, we have integrated the device tree our Linux kernel is using into custom u-boot source code. This step is not clearly explained in the porting guide you referenced, but we think it makes sense, as hardware setup is exactly the same for the kernel and for the boot-loader.

Related with board-detection logic (board_is_*() functions) we have modified all the board_is_* () functions to return 0 and removed the custom board_is_cct returning 1. We are not sure if that is enough or we should remove all these functions completely. Explanation in the porting guide is too open to know exactly what must be done.

If we use old SPL and new u-boot, then we see the SPL in the serial console loading, but when it tries to load the u-boot.img image, it simply stops showing nothing on the serial console. This is the log we see:

U-Boot SPL 2015.10 (Jun 14 2016 - 16:09:45)
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
cpsw
cpsw Waiting for PHY auto negotiation to complete... done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.1.110 (1260 ms)
Using cpsw device
TFTP from server 192.168.1.44; our IP address is 192.168.1.110
Filename 'platform/raption/firmware/u-boot.img'.
Load address: 0x807fffc0
Loading: ##############################################################
         1.3 MiB/s
done
Bytes transferred = 907196 (dd7bc hex)

Related with CCS debugger, we didn't know nothing about that tool. We have installed it just for testing. But we think that tool needs additional hardware to debug our board. It could be helpful if you could provide some link/info explaining which hardware must be used (probably we need to purchase it) and how that hardware must be connected/used with our custom board to debug it.

Many thanks in advance.

Kind regards.

Hello Judith.

Just to update some improvements... we have been able to see something on the serial console using an U-Boot version v2014.04 directy downloaded from gitlab https://github.com/u-boot/u-boot.git, this commitID dda0dbfc69f3d560c87f5be85f127ed862ea6721.

U-Boot SPL 2014.04 (Jul 26 2023 - 14:19:29)
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

Adding some logs we have arrived until the function preloader_console_init(). That function is setting up the serial console. It is called from this source code file: arch/arm/cpu/armv7/am33xx/board.c

/*
 * This requires UART clocks to be enabled.  In order for this to work the
 * caller must ensure that the gd pointer is valid.
 */
void preloader_console_init(void)
{
        gd->bd = &bdata;
        gd->baudrate = CONFIG_BAUDRATE;

        serial_init();          /* serial communications setup */

        gd->have_console = 1;

        puts("\nU-Boot SPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
                        U_BOOT_TIME ")\n");
#ifdef CONFIG_SPL_DISPLAY_PRINT
        spl_display_print();
#endif
}

We are searching something similar on the current u-boot version to try to force the same configuration. We will come back if we found something else that could be of some interest.

Kind regards.

Hello again Judith.

We have finally been able to compile a custom u-boot that is already displaying logs on the serial console and shows the u-boot menu properly:

<debug_uart>
Bad EEPROM or unknown board, cannot configure pinmux.
U-Boot SPL 2021.01-00003-g536085c3ac (Jul 27 2023 - 13:55:11 +0000)
Trying to boot from eth device
eth0: eth_cpsw
eth_cpsw Waiting for PHY auto negotiation to complete.... done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.1.110 (1005 ms)
Using eth_cpsw device
TFTP from server 192.168.1.44; our IP address is 192.168.1.110
Filename 'platform/raption/firmware/u-boot.img'.
Load address: 0x82000000
Loading: #################################################################
         #################################################################
         ######################################
         1.7 MiB/s
done
Bytes transferred = 859092 (d1bd4 hex)
WDT:   Started with servicing (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... <ethaddr> not set. Validating first E-fuse MAC
Net:   Could not get PHY for ethernet@4a100000: addr 1830841711
eth2: ethernet@4a100000
Hit any key to stop autoboot:  0 
## Error: "bootcmd_nand0" not defined
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-30-45-11-b2-70-c3
Retrieving file: pxelinux.cfg/00000000
Retrieving file: pxelinux.cfg/0000000
Retrieving file: pxelinux.cfg/000000
Retrieving file: pxelinux.cfg/00000
Retrieving file: pxelinux.cfg/0000
Retrieving file: pxelinux.cfg/000
Retrieving file: pxelinux.cfg/00
Retrieving file: pxelinux.cfg/0
Retrieving file: pxelinux.cfg/default-arm-am33xx-cct
Retrieving file: pxelinux.cfg/default-arm-am33xx
Retrieving file: pxelinux.cfg/default-arm
Retrieving file: pxelinux.cfg/default
Config file not found
=> 

The main problem was related with some missing CONFIG_ variables:

> CONFIG_DEBUG_UART_BASE=0x44e09000
> CONFIG_DEBUG_UART_CLOCK=48000000
> CONFIG_DEBUG_UART=y
> CONFIG_DEBUG_UART_OMAP=y
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_DEBUG_UART_ANNOUNCE=y

This missing variables are properly documented in your porting guide (setup early (debug) UART). We weren't aware these variables were directly related with this issue until investigated deeper into this issue. So the problem related with the serial console is fixed! :-)

Now we have a new issue related with ethernet. As this issue is related with the same process of porting a custom u-boot for this particular board, we prefer not opening a new issue. Here is the new problem described:

We are setting up the TCP/IP environment: 

=> setenv ipaddr 192.168.1.50
=> setenv netmask 255.255.255.0
=> setenv gatewayip 192.168.1.1
=> setenv netmask 255.255.255.0

However, after that, sending a ping to the TFTP server fails:

=> ping 192.168.1.44
ping failed; host 192.168.1.44 is not alive

However, as you can see, the u-boot-spl.bin is loading the SPL image properly via ethernet using server IP 192.168.1.44 (this IP is alive):

TFTP from server 192.168.1.44; our IP address is 192.168.1.110
Filename 'platform/raption/firmware/u-boot.img'.
Load address: 0x82000000
Loading: #################################################################
         #################################################################
         ######################################
         1.7 MiB/s
         

We see this error when loading the u-boot.img boot-loader that seems to be related with some ethernet issue:

Net:   Could not get PHY for ethernet@4a100000: addr 1830841711
eth2: ethernet@4a100000

Right now we continue investigating this issue, as this u-boot is still not completely functional. If you have some information useful to manage this issue, please let us know. We'll come back as soon as we have more information related. Many thanks!

Hi Ivan,

Im glad you are seeing prints now.

Unfortunately the engineer who works with Ethernet is out until Monday.

But looking at the new issue, did you set serverip in U-boot environment?
I do not see it here:
=> setenv ipaddr 192.168.1.50
=> setenv netmask 255.255.255.0
=> setenv gatewayip 192.168.1.1
=> setenv netmask 255.255.255.0

~ Judith

Hello Judith.

Just reporting there is no big progress from our site and we are still blocked with the ethernet issue.

We are writing just to provide new relevant information:

The Ethernet PHY 8710A (Microchip Technology Inc, old SMSC) is used in our board. The driver is included adding CONFIG_PHY_SMSC=y in u-boot configuration.

We also have enabled CONFIG_NET_RANDOM_ETHADDR=y to declare a random ethaddr MAC address. This works fine:

=> print ethaddr
ethaddr=30:45:11:b2:70:c3

We also included "serverip" environ variable as suggested, but still fails:

=> setenv ipaddr 192.168.1.50
=> setenv netmask 255.255.255.0
=> setenv gatewayip 192.168.1.1
=> setenv serverip 192.168.1.44

=> ping 192.168.1.44
ping failed; host 192.168.1.44 is not alive

Even pinging to the local ipaddr fails, as you can see below:

=> ping 192.168.1.50
ping failed; host 192.168.1.50 is not alive

We can see the PHY status register:

=> mii dump 0 0
0. (3100) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:2000) 0. 6,13 = b01 speed selection = 100 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)


=> mii dump 0 1
1. (782d) -- PHY status register --
(8000:0000) 1.15 = 0 100BASE-T4 able
(4000:4000) 1.14 = 1 100BASE-X full duplex able
(2000:2000) 1.13 = 1 100BASE-X half duplex able
(1000:1000) 1.12 = 1 10 Mbps full duplex able
(0800:0800) 1.11 = 1 10 Mbps half duplex able
(0400:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0000) 1. 8 = 0 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0000) 1. 6 = 0 MF preamble suppression
(0020:0020) 1. 5 = 1 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0004) 1. 2 = 1 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities

According to LAN8710A datasheet, link status value 1 means the link is UP. So, this seems it should be working fine. But as you can see, it doesn't work as expected. We will continue investigating, but some advice with this could be helpfull.

Many thanks in advance!

Hi,

Sorry for the delay, will forward this to out Ethernet expert. Thanks for your patience.

~ Judith

Hello Judith.

We have fixed the ethernet issue with some customizations in our device tree overlay. Now we can ping the serverip:

=> ping 192.168.1.44
link up on port 0, speed 100, full duplex
Using ethernet@4a100000 device
host 192.168.1.44 is alive

We also can transfer files from TFTP server. That works great.

However, we can't ping the local ipaddr:

=> ping 192.168.1.50
link up on port 0, speed 100, full duplex
Using ethernet@4a100000 device

ARP Retry count exceeded; starting again
ping failed; host 192.168.1.50 is not alive

This is a minor issue, but it would be nice to understand why pinging the local ipaddr doesnt' work.

Just for reference, this is the current device tree overlay that works with our UART and ETH.

/dts-v1/;

#include "am33xx.dtsi"
// #include <dt-bindings/pinctrl/am33xx-pads.h>

/ {
    model = "TI AM335x CCT";
    compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";

    aliases {
        ethernet0 = &cpsw_emac0;
    };

    memory {
        device_type = "memory";
        reg = <0x80000000 0x10000000>; /* 256 MB */
    };

    chosen {
        stdout-path = &uart0;
    };
};

&uart0 {
    status = "okay";
};

&cpsw_emac0 {
    phy-handle = <&ethphy0>;
    phy-mode = "mii";
};

&davinci_mdio {
    ethphy0: ethernet-phy@0 {
        reg = <0>;
    };
};

&mac {
    status = "okay";
};

Now, we have started dealing with the eMMC, as we try to save the u-boot environment, and we get this error: 

=> saveenv
Saving Environment to FAT... Failed (1)

We have started working on this. Probably we will come back later on with new issues related. Please don't close this ticket until we have a fully functional u-boot. 

Many thanks in advance!

Hello again Judith.

We are still dealing with eMMC. The new u-boot is listing two MMCs:

=> mmc list
OMAP SD/MMC: 0
OMAP SD/MMC: 1

=> mmc info
=> echo $?
1

=> load mmc 1:2 0x80F80000 am335x-cct.dtb
=> echo $?
1

As you can see, the "load mmc" command returns a "1" (retcode failure).
However, this command works fine when using the old u-boot (U-Boot 2015.10):

=> load mmc 1:2 0x80F80000 am335x-cct.dtb
reading am335x-cct.dtb
36771 bytes read in 7 ms (5 MiB/s)
=> echo $?
0

Our mmcblk0 device has 4 partitions (p1, p2, p3 and p4):

179        0    1888256 mmcblk0
  179        1      16376 mmcblk0p1
  179        2      16384 mmcblk0p2
  179        3     262144 mmcblk0p3
  179        4    1593344 mmcblk0p4

That "am335x-cct.dtb" file is located in p2 partition. This partition also stores the kernel uImage file:

$ mount /dev/mmcblk0p2 /tmp/removable
$ ls -l /tmp/removable/
total 4803
-rwxr-xr-x    1 root     root         36771 Jan  1  2000 am335x-cct.dtb
-rwxr-xr-x    1 root     root       4880648 Jan  1  2000 uImage

Just for reference, this is the current DT overlay we are using to enable eMMC's:

# cat arch/arm/dts/am335x-cct.dts
/*
 * Copyright (C) 2023 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;

#include "am33xx.dtsi"
#include <dt-bindings/pwm/pwm.h>
#include <dt-bindings/interrupt-controller/irq.h>

/ {
    model = "TI AM335x CCT";
    compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";

    aliases {
        ethernet0 = &cpsw_emac0;
    };

    memory {
        device_type = "memory";
        reg = <0x80000000 0x10000000>; /* 256 MB */
    };

    vbat: fixedregulator@0 {
	compatible = "regulator-fixed";
	regulator-name = "vbat";
	regulator-min-microvolt = <5000000>;
	regulator-max-microvolt = <5000000>;
	regulator-boot-on;
    };

    wl12xx_vmmc: fixedregulator@2 {
        pinctrl-names = "default";
        pinctrl-0 = <&wl12xx_gpio>;
        compatible = "regulator-fixed";
        regulator-name = "vwl1271";
        regulator-min-microvolt = <1800000>;
        regulator-max-microvolt = <1800000>;
        gpio = <&gpio1 29 0>;
        startup-delay-us = <70000>;
        enable-active-high;
    };

    chosen {
        stdout-path = &uart0;
	tick-timer = &timer2;
    };
};

&am33xx_pinmux {

        i2c0_pins: pinmux_i2c0_pins {
                pinctrl-single,pins = <
                        AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)       /* i2c0_sda.i2c0_sda */
                        AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)       /* i2c0_scl.i2c0_scl */
                >;
        };


	mmc1_pins: pinmux_mmc1_pins {
		pinctrl-single,pins = <
			0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
		>;
	};

	mmc2_pins: pinmux_mmc2_pins {
		pinctrl-single,pins = <
			0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /* gpmc_wpn.gpio0_31 */
			0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
			0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
			0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
			0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
			0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
			0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
		>;
	};

        wl12xx_gpio: pinmux_wl12xx_gpio {
                pinctrl-single,pins = <
                        AM33XX_IOPAD(0x87c, PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_csn0.gpio1_29 */
                >;
        };

};

&i2c0 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c0_pins>;

        status = "okay";
        clock-frequency = <400000>;

        tps: tps@2d {
                reg = <0x2d>;
        };
};


&uart0 {
    status = "okay";
};

&cpsw_emac0 {
    phy-handle = <&ethphy0>;
    phy-mode = "mii";
};

&davinci_mdio {
    ethphy0: ethernet-phy@0 {
        reg = <0>;
    };
};

&mac {
    status = "okay";
};


#include "tps65910.dtsi"

&tps {
	vcc1-supply = <&vbat>;
	vcc2-supply = <&vbat>;
	vcc3-supply = <&vbat>;
	vcc4-supply = <&vbat>;
	vcc5-supply = <&vbat>;
	vcc6-supply = <&vbat>;
	vcc7-supply = <&vbat>;
	vccio-supply = <&vbat>;

	regulators {
		vrtc_reg: regulator@0 {
			regulator-always-on;
		};

		vio_reg: regulator@1 {
			regulator-always-on;
		};

		vdd1_reg: regulator@2 {
			// VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance
			regulator-name = "vdd_mpu";
			regulator-min-microvolt = <912500>;
			regulator-max-microvolt = <1312500>;
			regulator-boot-on;
			regulator-always-on;
		};

		vdd2_reg: regulator@3 {
			// VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance
			regulator-name = "vdd_core";
			regulator-min-microvolt = <912500>;
			regulator-max-microvolt = <1150000>;
			regulator-boot-on;
			regulator-always-on;
		};

		vdd3_reg: regulator@4 {
			regulator-always-on;
		};

		vdig1_reg: regulator@5 {
			regulator-always-on;
		};

		vdig2_reg: regulator@6 {
			regulator-always-on;
		};

		vpll_reg: regulator@7 {
			regulator-always-on;
		};

		vdac_reg: regulator@8 {
			regulator-always-on;
		};

		vaux1_reg: regulator@9 {
			regulator-always-on;
		};

		vaux2_reg: regulator@10 {
			regulator-always-on;
		};

		vaux33_reg: regulator@11 {
			regulator-always-on;
		};

		vmmc_reg: regulator@12 {
			regulator-min-microvolt = <1800000>;
			regulator-max-microvolt = <3300000>;
			regulator-always-on;
		};
	};
};

&mmc1 {
	status = "okay";
	vmmc-supply = <&vmmc_reg>;
	bus-width = <4>;
	pinctrl-names = "default";
	pinctrl-0 = <&mmc1_pins>;
	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};

&mmc2 {
	status = "okay";
	vmmc-supply = <&wl12xx_vmmc>;
	ti,non-removable;
	bus-width = <4>;
	cap-power-off-card;
	pinctrl-names = "default";
	pinctrl-0 = <&mmc2_pins>;
};

Please, some help to debug this issue could be very useful. We are blocked with this.

Many thanks in advance!

Hello again.

We are still blocked with the eMMC issue. Just wanted to share the (small) progress we made:

The board has two MMC devices:
    - SD (mmc1 node in DT)
    - eMMC (mmc2 node in DT).

We added this two macros in the drivers/mmc/mmc.c file to enable MMC debugging.

#define CONFIG_MMC_TRACE
#define DEBUG

Now we can see this error when booting the board:

U-Boot 2021.01-00005-g99fe97fa9f-dirty (Aug 24 2023 - 11:52:18 +0000)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x CCT
DRAM:  256 MiB
WDT:   Started with servicing (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... <ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000, eth3: usb_ether
Hit any key to stop autoboot:  0
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:8
                ARG                      0x000001aa
                RET                      -110
CMD_SEND:55
                ARG                      0x00000000
                RET                      -110
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:1
                ARG                      0x00000000
                RET                      -110
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:8
                ARG                      0x000001aa
                RET                      -110
CMD_SEND:55
                ARG                      0x00000000
                RET                      -110
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:1
                ARG                      0x00000000
                RET                      -110

This -110 errno code is -ETIMEDOUT. We think there is some DT issue, as eMMC device can't be detected.

Whenever we try to access the mmc dev 1 (eMMC), we see similar logs:

=> mmc dev 1
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:8
                ARG                      0x000001aa
                RET                      -110
CMD_SEND:55
                ARG                      0x00000000
                RET                      -110
CMD_SEND:0
                ARG                      0x00000000
                MMC_RSP_NONE
CMD_SEND:1
                ARG                      0x00000000
                RET                      -110

When we try to access mmc dev 0 (SD), we dont see this kind of logs, but retcode 1 is returned:

=> mmc dev 0
=> echo $?
1

We have tested with different DT customizations with no luck. I can provice eMMC connection schema and full custom DT if can be helpful. We will come back if we have some new progress. Many thanks in advance!

Hi,

Are you still having trouble with the Ethernet? If so we should file another e2e post regarding ethernet only.

In the meantime if you are still having trouble you need to verify that the packets are leaving the board. The easiest is to boot to Linux to look at the results of ethtool -S < the interface you want to check>.

Best Regards,

Schuyler

Hello Schuyler.

We already fixed the ethernet issue. It is reported in this post (just follow my messages). The fix was done by customizing the device tree properly.

Now we are still dealing with eMMC issues, also reported in this post.

If it is possible, we prefer not closing this ticket until this u-boot is completely useful, as creating a new post creates a new context, and this eMMC issue is completely related with information previously reported on this post.

Many thanks in advance for your feedback.

Kind regards,

Ivan

Hi Ivan,

I will work on finding the correct team member to help. I will respond tomorrow.

Best Regards,

Schuyler