IMX6Q Custom U-Boot Help

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX6Q Custom U-Boot Help

1,164 Views
kcassar
Contributor II

Hi,

We are currently trying to boot a custom board by editing i.MX6Q mx6sabresd files.

On our board we have an eMMC chip in SD port 3 and a microSD in SD port 4.

We would like to boot from microSD is slot 4.

What files do we need to edit to enable this to happen?

Our boot DIP switches are set to the correct port, however through the serial terminal, all we are seeing is;

U-Boot SPL 2018.11+fslc+g6e25ce6f3c (Apr 30 2019 - 11:10:01 +0100)
Trying to boot from MMC1

We are building using Yocto and are currently building u-boot manually from within Yocto to make use of our own ported files (files ported from mx6sabresd):
/board/hgldynamics/mx6dragonfly/Kconfig
/board/hgldynamics/mx6dragonfly/Makefile
/board/hgldynamics/mx6dragonfly/mx6dragonfly.c
/configs/mx6dragonfly_defconfig
/include/configs/mx6dragonfly.h
/include/configs/mx6dragonfly_common.h

In /board/hgldynamics/mx6dragonfly/mx6dragonfly.c we've attempted to modify the uSDHC pads and related functions appropriately to support or custom board and in /include/configs/mx6dragonfly.h we've set to CONFIG_SYS_MMC_ENV_DEV to what we think is the correct value to select the appropriate port. We have also customised the DCD tables in  /board/hgldynamics/mx6dragonfly/mx6dragonfly.c to match our RAM configuration (or at least we think so).

We've added the appropriate entries to:
/arch/arm/mach-imx/mx6/Kconfig

We can build a vanilla unmodified mx6sabresd u-boot, kernel and filesystem and these work on our freescale sabresd dev board fine.

Any help would be greatly appreciated.

Cheers,

Kyle.

Labels (1)
0 Kudos
2 Replies

945 Views
kcassar
Contributor II

Hi,

Thanks for your reply. We managed to get around this problem by mapping to the correct SD port in mx6dragonfly.h we modified the following to be as below:

#define CONFIG_SYS_FSL_USDHC_NUM 2
#if defined(CONFIG_ENV_IS_IN_MMC)
#define CONFIG_SYS_MMC_ENV_DEV 1
#endif

In mx6dragonfly.c we modified:

int board_mmc_getcd(struct mmc *mmc)

To use USDHC3_BASE_ADDR and USDHC4_BASE_ADDR to match our custom board.
And set the 2 cases to always return 1 as these are always present
And we also made complimentary tweaks to:

int board_mmc_init(bd_t *bis)

We are now getting stuck at this point (note we have added extra printf calls in all the functions in mx6dragonfly.c and this extra logging is displayed in the terminal output below). 

U-Boot SPL 2018.11-dirty (May 02 2019 - 13:28:53 +0100)
board_init_f: Clear the BSS
board_init_f: calling board_init_r
Trying to boot from MMC1
board_mmc_init
board_mmc_init: CONFIG_SPL_BUILD is defined
board_mmc_init: set struct src *psrc, calling readl(&psrc->sbmr1)
board_mmc_init: readl(&psrc->sbmr1) has returned
board_mmc_init: reg = 15
board_mmc_init: reg & 3 = 3
(CONFIG_SPL_BUILD) setting pads for uSDHC4 (uSD) on MMC1
(CONFIG_SPL_BUILD) calling fsl_esdhc_initialize
board_mmc_getcd: USDHC4_BASE_ADDR
board_mmc_getcd: ret = 1
spl_start_uboot


U-Boot 2018.11-dirty (May 02 2019 - 13:28:53 +0100)

CPU: Freescale i.MX6Q rev1.6 996 MHz (running at 792 MHz)
CPU: Automotive temperature grade (-40C to 125C) at 29C
Reset cause: POR
Board: MX6-Dragonfly
I2C: ready
DRAM: dram_init
1 GiB
board_init
setup_spi
board_init: calling setup_i2c, is_mx6dq() == true
setup_display
setup_usb
power_init_board
MMC: board_mmc_init
board_mmc_init: CONFIG_SPL_BUILD is not defined
setting pads for eMMC (MMC0)
calling fsl_esdhc_initialize
setting pads for uSDHC (MMC1)
calling fsl_esdhc_initialize
FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... board_mmc_get_env_dev: devno = 3, overriding - returning dev index as CONFIG_SYS_MMC_ENV_DEV (1)
board_mmc_getcd: USDHC4_BASE_ADDR
board_mmc_getcd: ret = 1
*** Warning - bad CRC, using default environment

I have seen by searching the forum that the bad CRC isn't necessarily a problem, however we can't get past this message.

When we run a regular unmodified build on our sabresd dev board, rather than our custom board, we can boot fully into Linux and get beyond the steps above and do see equivalent debug up to the point above on the sabresd dev board.

The next few lines we are expecting to see are as below ( as obtained running on sabresd dev board)

PCI: pcie phy link never came up
No panel detected: default to Hannstar-XGA
enable_lvds
enable_backlight
Display: Hannstar-XGA (1024x768)
overwrite_console
In: serial
Out: serial
Err: serial

...

0 Kudos

945 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Kyle,

The customizations steps you have took look correct. You can find a very good explanation on what needs to be set up on the i.MX BSP Porting Guide which is available as part of the BSP Release documentation, it may be worth giving it a look in case you haven’t.

You mentioned that the unchanged u-boot boots correctly on the SABRE board, not your own customized board, is my understanding correct?

If you are seeing a uboot prompt on your custom board it means that the ROM is being able to boot from the intended source. Are you seeing the whole u-boot log and prompt or only the two lines above?

If u-boot can run but it won’t continue booting it could be that some of the boot parameters are not correct, so you would need to make sure that the boot arguments reflect your custom configuration.

Regards,

0 Kudos