Compiler/AM3352: porting u-boot config from older sdk

I've run through the options that I was using and all still seem to be active in menuconfig (but does not work - initially complaining about SYS_TEXT_BASE being an illegal value)

- the CONFIG_SYS_EXTRA_OPTIONS does look to be labelled as deprecated though

One thing I notice is that the CONFIG_TARGET_AM335X is being set in my build even though I have not got this in my config (replacing it with MYBOARD)

I can see in the git commit history where this string was removed from the devconfig - but I cannot find where this is presently being supplied from: does anyone know where this might be coming from in the u-boot-ti-staging recipe?

All the best

- Richard

Richard,

there was a related E2E thread back in February of someone trying to get NOR boot to work with the current SDK. The main post is this one here:

https://e2e.ti.com/support/processors/f/791/p/877940/3257343#3257343

But from the discussion it looks like it was not fully closed. Pinmux will need to be added to the board files too, but there might be other pieces missing. If you are willing to debug this by way of JTAG and/or enabling the debug UART feature (see the Setup early (debug) UART section in our U-Boot board port document here: https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html) we might be able to get this working but this will probably take a few iterations. Let me know.

Regards, Andreas

I suppose my main question is whether to try and port the config that was working 
- or to try and start from scratch with the most recent SDK

Thanks for any help

-Richard

Hi Richard,

Richard_McAleer said:

I suppose my main question is whether to try and port the config that was working 

The problem is, if with "config" you mean "defconfig", that along won't work. Much of U-Boot's "configuration" is in board.c files / mux.c type files, device specific header files as well as the DTS in addition to the defconfig (and all Kconfig files throughout the U-Boot tree, which is were the defaults are coming from). There are many changes throughout those different files as U-Boot evolves, so it'll be easy to miss items if you were to simply copy over various artifacts, resulting in hard-to-debug problems of various types. This being said I'd start with a clean board port, and then integrate pieces from your older but working solution that you need like NOR boot step by step. See our U-Boot board port guide as a starting point: https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html

Regards, Andreas

Thanks Andreas

I had suspected that a clean port would be the best way forward; so it's good to have it confirmed.

I'll have a read through the documentation you've linked to and see where to start on this

I suspect with the hardware I have that using the early debug uart is going to be the best way forward.

My previous workflow with the old SDK was to create an SD image that could be booted from and tested
- then to use u-boot to copy the files off on to the SPI ROM (using the byteswapped MLO) using environment variables that were executed as scripts

- so really U-boot does not need much more functionality than accessing an MMC/SD card and SPI NOR

In the meantime do you know what sets the CONFIG_TARGET_AM335X_EVM variable now that it is not in the defconfig? 

Thanks

- Richard

Hi Richard,

Richard_McAleer said:

My previous workflow with the old SDK was to create an SD image that could be booted from and tested
- then to use u-boot to copy the files off on to the SPI ROM (using the byteswapped MLO) using environment variables that were executed as scripts

- so really U-boot does not need much more functionality than accessing an MMC/SD card and SPI NOR

That sounds like a plan.

Richard_McAleer said:

In the meantime do you know what sets the CONFIG_TARGET_AM335X_EVM variable now that it is not in the defconfig? 

It is set by the Kconfig build system, so you won't find it when you just search for the full name of the CONFIG option. Usually it's best to drop any such prefix. This way you'll also catch any instances that involve SPL and TPL as well.

a0797059@jiji:~/git/u-boot (ti-u-boot-2019.01-next-dev)
$ git grep -A 33 'config.*TARGET_AM335X_EVM'
arch/arm/mach-omap2/am33xx/Kconfig:config TARGET_AM335X_EVM
arch/arm/mach-omap2/am33xx/Kconfig-     bool "Support am335x_evm"
arch/arm/mach-omap2/am33xx/Kconfig-     select BOARD_LATE_INIT
arch/arm/mach-omap2/am33xx/Kconfig-     select DM
arch/arm/mach-omap2/am33xx/Kconfig-     select DM_GPIO
arch/arm/mach-omap2/am33xx/Kconfig-     select DM_SERIAL
arch/arm/mach-omap2/am33xx/Kconfig-     select TI_I2C_BOARD_DETECT
arch/arm/mach-omap2/am33xx/Kconfig-     imply CMD_DM
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_DM
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_DM_SEQ_ALIAS
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_ENV_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_EXT_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_FAT_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_GPIO_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_I2C_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_LIBCOMMON_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_LIBDISK_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_LIBGENERIC_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_MMC_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_NAND_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_OF_LIBFDT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_POWER_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_SEPARATE_BSS
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_SERIAL_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_SYS_MALLOC_SIMPLE
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_WATCHDOG_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     imply SPL_YMODEM_SUPPORT
arch/arm/mach-omap2/am33xx/Kconfig-     help
arch/arm/mach-omap2/am33xx/Kconfig-       This option specifies support for the AM335x
arch/arm/mach-omap2/am33xx/Kconfig-       GP and HS EVM development platforms. The AM335x
arch/arm/mach-omap2/am33xx/Kconfig-       GP EVM is a standalone test, development, and
arch/arm/mach-omap2/am33xx/Kconfig-       evaluation module system that enables developers
arch/arm/mach-omap2/am33xx/Kconfig-       to write software and develop hardware around
arch/arm/mach-omap2/am33xx/Kconfig-       an AM335x processor subsystem.

Regards, Andreas

Hi Andreas

I believe those parts in the Kconfigs were the definitions of the TARGET; previously I would patch that file to include a definition for my new MYBOARD target and direct the compiler to that via an entry in the defconfig

It appears now that there is no TARGET defined in the defconfig and I am wondering how this is provided to the build?

Thanks for the assistance

- Richard

Hi Richard,

that is a good question! I had a quick look, and what is selecting the TARGET_* is actually determined by the sequence in which the targets are defined in arch/arm/mach-omap2/am33xx/Kconfig. So the build system will pick up whatever is the first one listed as a default, in this case TARGET_AM335X_EVM. If you edit this file to re-arrange the order of the TARGET_* blocks you'll see this changing.

Anyways this doesn't really matter you should be using 'make [...] menuconfig' to edit the configuration, and then use 'make [...] savedefconfig' to generate a new defconfig file for your board to be copied into configs/*. It will have all the right definitions.

Regards, Andreas

Thanks Andreas

That's a good bit of info to know 

I'll be sure to go through menuconfig for any changes, as I'm ultimately trying to build all this via poky and I'd like to keep the defconfig clean for patching in.

I've managed to get as far as running u-boot on SD card now; so the u-boot SPL was able to load u-boot from SD card.

Looks as though u-boot itself at the moment is unable to read the MMC or SPI flash

the only mmc command that returns anything is list

=> mmc list
OMAP SD/MMC: 0

and I see no output from fatls mmc 0  on this SD card that contains my MLO and u-boot.img

when I was last working on this the baseline I took for the dts was that of the boneblack; this looks to be still very similar to what I have (but quite different from the evm dts)

I presume that this is the most likely place to start looking to solve my immediate issue; I wonder if you can suggest any other likely places to look?

All the best

- Richard

Richard_McAleer said:

when I was last working on this the baseline I took for the dts was that of the boneblack; this looks to be still very similar to what I have (but quite different from the evm dts)

To maximize chances for success I'd probably start with a baseline (existing board) that has the same eMMC/MMC connectivity, so you can inherit the known-good MMC setup including what's defined related to that in the board.c/mux.c board files, defconfig, and what's configured in the device tree. Those things are all related to each other, and need to be just right for everything to work. Which brings us to...

Richard_McAleer said:

=> mmc list
OMAP SD/MMC: 0

and I see no output from fatls mmc 0  on this SD card that contains my MLO and u-boot.img

The fact that you have SPL loading U-Boot (as evident from you having reached the U-Boot prompt) means that your basic U-Boot infrastructure is able to read from MMC which is great. Then if loading anything from U-Boot prompt doesn't work this could be an issue with the U-Boot device tree file for your board.

Regards, Andreas

Andreas Dannenberg said:

The fact that you have SPL loading U-Boot (as evident from you having reached the U-Boot prompt) means that your basic U-Boot infrastructure is able to read from MMC which is great. Then if loading anything from U-Boot prompt doesn't work this could be an issue with the U-Boot device tree file for your board.

yes that looks to be the case and with a bit of a modification, essentially expanding the mmc1 entry with the missing components form the evm dts giving:

&mmc1 {
	status = "okay";
	vmmc-supply = <&vmmcsd_fixed>; /*this was the only entry in the original*/
	bus-width = <4>;
	pinctrl-names = "default";
	pinctrl-0 = <&mmc1_pins>;
	cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};

I have got access to the SD card from the u-boot command line

Now I need to track down how to get SPI access from both u-boot and the SPL 

Thanks

- Richard

I've reached the point where u-boot is able to see the SPI NOR and the MMC
This was achieved though enabling the necessary flash type (STMICRO)
- and removing a patch that had previously been inserting the necessary info

So I am now able to boot from MMC and transfer data to the SPI NOR using u-boot commands (sf, mmc, fatls, mmtdparts)

The final bit of the puzzle is getting the SPL to see the SPI flash (and MMC for development purposes)

I have added a method to my board.c for the boot order

#ifdef CONFIG_SPL_BUILD
void board_boot_order(u32 *spl_boot_list)
{
spl_boot_list[0] = BOOT_DEVICE_MMC1;
spl_boot_list[1] = BOOT_DEVICE_NOR;

}
#endif

my hope would be that I could use this to help debug the execution of the SPL code on the SPI flash
- if it failed to load from NOR I could insert the SD card (the boot sequence GPIO pulls are done on the board in a way I cannot change)

however even with the SD card inserted it will fail to boot from it if the SPL is executed from the SPI flash

U-Boot SPL 2020.01-00004-gb55a80b1dc-dirty (Jul 22 2020 - 14:31:25 +1000)
Trying to boot from MMC1
spl: mmc: wrong boot mode
Trying to boot from NOR

it does however work if both are loaded from the MMC

U-Boot SPL 2020.01-00004-gb55a80b1dc-dirty (Jul 22 2020 - 14:31:25 +1000)
Trying to boot from MMC1
spl: mmc boot mode: fs

U-Boot 2020.01-00004-gb55a80b1dc-dirty (Jul 22 2020 - 14:31:25 +1000)

CPU : AM335X-GP rev 2.1

it would be good to understand what is different here as it should be the same code

Does the SPL rely on the chip ROM having configured the MMC hardware?

more importantly though is getting the SPL to load from NOR correctly

i notice in arch/arm/include/asm/arch-am33xx/spl.h
that BOOT_DEVICE_NOR is not defined; it appears to have been replaced with BOOT_DEVICE_XIP.

Using this value (1) still results in the NOR string being printed by: printf("Trying to boot from %s\n", loader->name);
in spl.c; is this the correct enum to be using for the boot device?

I can see it running through the code in spl_nor_load_image (spl_nor.c) but it's not entirely clear what code should be loading the image from the flash chip.

Any suggestions would be gratefully received.

All the best,
- Richard

From reading the code it looks as though CONFIG_SYS_UBOOT_BASE should be an address where the image for uboot is stored.

Presumably this is somehow memory mapped so that the SPI interactions are transparent?

my u-boot image has been located at offset 0x20000 of my SPI NOR flash

- it would be good to know how this would relate to the SYS_UBOOT_BASE value (or indeed if my reading of this is completely wrong)

All the best

- Richard 

Hi Richard,

Richard_McAleer said:

CONFIG_SYS_UBOOT_BASE should be an address where the image for uboot is stored.

This is the address (usually in DDR) where U-Boot gets loaded to, not where it is stored in NOR (see more below).

Richard_McAleer said:

Presumably this is somehow memory mapped so that the SPI interactions are transparent?

XIP is only used for the ROM code handing over to the SPL, which is transparent to SPL really. From the SPL onwards, we'd be using SPL_NOR_SUPPORT. Which means, the common/spl/spl_nor.c driver is used to simply copy the boot artifacts such as U-Boot from NOR to their final location (DDR, in case of U-Boot). While this is still memory mapped, this is not XIP. But to your question, yes, the SPI interactions will remain transparent.

Richard_McAleer said:

my u-boot image has been located at offset 0x20000 of my SPI NOR flash

The location where the U-Boot image needs to be located in NOR is defined through CONFIG_SYS_SPI_U_BOOT_OFFS. In case of our AM335x EVM header file this is set to '#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x20000'

Regards, Andreas

Hi Richard,

Richard_McAleer said:

my hope would be that I could use this to help debug the execution of the SPL code on the SPI flash
- if it failed to load from NOR I could insert the SD card (the boot sequence GPIO pulls are done on the board in a way I cannot change)

however even with the SD card inserted it will fail to boot from it if the SPL is executed from the SPI flash

?

1 2 3 4

U-Boot SPL 2020.01-00004-gb55a80b1dc-dirty (Jul 22 2020 - 14:31:25 +1000) Trying to boot from MMC1 spl: mmc: wrong boot mode Trying to boot from NOR

Usually one does not switch boot media at the SPL point, so I'm not surprised that you are running into issues. This doesn't mean it can't be done, since it's all just code. Two things probably worth experimenting with:

1. Overriding board_boot_order() won't be enough. You also need to customize spl_boot_mode() which is important for MMC boot specifically. This function is defined in arch/arm/mach-omap2/boot-common.c. So you might need to customize the code that configures gd->arch.omap_boot_mode in that file to get a proper boot mode. You can add debug prints to the common/spl/spl_mmc.c driver to see what effective boot mode you get in a working case, and then transplant based on that.
2. Make sure you have all the needed pinmux active for the different boot modes you want to support in your board/ti/am335x/mux.c -like file, like configure_module_pin_mux(mmc0_pin_mux); and configure_module_pin_mux(spi0_pin_mux);

Richard_McAleer said:

more importantly though is getting the SPL to load from NOR correctly

i notice in arch/arm/include/asm/arch-am33xx/spl.h
that BOOT_DEVICE_NOR is not defined; it appears to have been replaced with BOOT_DEVICE_XIP.

Using this value (1) still results in the NOR string being printed by: printf("Trying to boot from %s\n", loader->name);
in spl.c; is this the correct enum to be using for the boot device?

Yes.

Richard_McAleer said:

I can see it running through the code in spl_nor_load_image (spl_nor.c) but it's not entirely clear what code should be loading the image from the flash chip.

That's good. It might be worth printing some of the bytes that are getting loaded, to make sure the right U-Boot binary is getting loaded as you have it on your host PC. And to trace down where it fails. Actually that is a good opportunity to look at using a JTAG debugger, it will greatly speed up debugging. Often it is just a simple small issue that needs to be fixed that becomes quickly evident when stepping through the actual code.

Also when you say you programmed your U-Boot image to NOR address 0x20000, you are referring to u-boot.img, correct?

Regards, Andreas

Thanks for the tips

I'll put the SPL MMC / NOR switching on the back burner for now as I've got a way of working around this.

JTAG would be nice but is unfortunately impossible with the hardware at present.

Andreas Dannenberg said:

when you say you programmed your U-Boot image to NOR address 0x20000, you are referring to u-boot.img, correct?

yes that's where I've put u-boot.img 
the actual operation in u-boot is using partitions defined with mtdpart and that's all doing exactly what I need

I've confirmed that my u-boot environment scripts are able to put everything they need to in to the expected locations of the SPI NOR 
- hexdumps of the file headers match those loaded from MMC and those match the values read back from SPI NOR

It's just this last step of jumping from SPI NOR SPL to SPI NOR u-boot that I need to solve.

I'll review the code's handling of CONFIG_SYS_SPI_U_BOOT_OFFS and SPL_NOR_SUPPORT 
Hopefully if I can find where it's doing the transfer from SPI to RAM  I should be able to see what needs to be set

Thanks for the help

- Richard

The only reference I can find to the U_BOOT_OFFSET is in spl_spi.h

unsigned int __weak spl_spi_get_uboot_offs(struct spi_flash *flash)
{
return CONFIG_SYS_SPI_U_BOOT_OFFS;
}

SPL_LOAD_IMAGE_METHOD("SPI", 1, BOOT_DEVICE_SPI, spl_spi_load_image);

whcih would suggest this is active when the boot device is SPI rather than NOR
however I find if I try to use BOOT_DEVICE_SPI it throws the:
SPL: Unsupported Boot Device!
error from boot_from_devices in spl.c
which is due to it not finding a loader in spl_ll_find_loader so something is not bound up correctly there at present

The code in spl_spi does look more like the code I would expect that the text in spl_nor.c (which I can't at the moment see attempting any reads over the spi) 

SPL_NOR_SUPPORT throws hits in the code only under the archs for imx8 and mediatek which I don't think are relevent

Thanks 

- Richard

if I enable CONFIG_SPL_SPI_LOAD to include this file 

via the make file entry obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o

it appears to crash the build due to 

drivers/built-in.o:(.u_boot_list_2_uclass_2_spi+0x8): undefined reference to `dm_scan_fdt_dev'

which is presumably due to some other effect of enabling this MACRO as there's no reference to that function in the spl_spi.c file

what I am trying to work out at the moment is whether it is most practical to continue working through the build switches available

or whether I start trying to spin code to do the lifting out of SPI NOR: either directly within spl_nor.c or identifying the appropriate weak functions to overload within my board.c file
- as at present the NOR loader looks do to little but execute the memcpy at the end

memcpy((void *)(unsigned long)spl_image->load_addr,
	       (void *)(spl_nor_get_uboot_base() + sizeof(struct image_header)),
	       spl_image->size);

and I can see that there already exist a couple of options for different platforms that are bypassed in my code

thanks for any suggestions

- Richard

Richard,

Richard_McAleer said:

and inserted 

 u-boot,dm-spl;

to the devices for the uart, spi, spi-flash and mmc devices in the .dts

Many thanks for closing the loop here and sharing your solution. Yes the U-Boot SPL device tree blob build-time optimization is tricky and can create a lot of issues as well as the implicit inclusion of "*-u-boot.dtsi" DTSI files (which you are not affected by, only some platforms are) - both have cost me hours of debug time in the past. Let me make a note so we can add this to a future update of our board port guide at https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/How_to_Guides/Board_Port/U-Boot.html

Regards, Andreas

Thanks for the help Andreas

seemed like a good idea not to leave the thread hanging at 80% complete

All the best,

- Richard