This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
I am trying to create MLO and UBoot images for the AM335x Starter Kit. I am using Ubuntu 10.04.3, and on it installed ti-sdk-am335x-evm-06.00.00.00 (not sure if I actually need this apart from creating the SD card) and AM335X-LINUX-PSP-04.06.00.08. I also installed the arago-2011.09-armv7a-linux-gnueabi-sdk toolchain (http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html) a prerequisite according to the 0004-AM335x-u-boot-User-Guide.pdf document that came with the PSP (docs directory). From the command line it's essentially this:
cd AM335X-LINUX-PSP-04.06.00.08/src/u-boot/u-boot-04.06.00.08/
export PATH=<absolute path>/arago-2011.09/armv7a/bin/:$PATH
rm -rf am335x
make O=am335x CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm am335x_evm
There are 2 problems I have with the MLO binary produced:
1) it's not the same size as the pre-build binary (84990 vs 82734) - should I be concerend about this?
2) ultimately I want to build it for the Starter Kit (which has different DDR etc.) According to the ti-sdk-am335x-evm-06.00.00.00 release notes it supports the Starter Kit, so surely the last argument ("am335x_evm")needs to be different?
I get the feeling I'm missing something fundamental. Some advice would be most welcome please?
Hi Valid,
I type the instruction for compiling the MLO and u-boot: (I work with Ubuntu 12.04)
You need to run the <SDK_folder>/bin/setup-package-install.sh script that will install some needed packages to your host linux system. The included toolchain is Linaro GCC 2013.03 (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03). The toolchain resides in <SDK_folder>/linux-devkit/sysroots/i686-arago-linux/usr/bin.
Setup the system:
~/ti-sdk-am335x-evm-06.00.00.00/bin$
sudo ./setup-package-install.sh
Export the needed environment:
export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm
export PATH=$PATH:$HOME/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin
Build instructions
How to build the U-Boot:
export ARCH=arm
export CROSS_COMPILE=~/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-
make am335x_evm
How to build the linux kernel:
export ARCH=arm
export CROSS_COMPILE=~/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-
make tisdk_am335x-evm_defconfig
make -j8 uImage
For the 2. please see:
http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling
BR
Ivan
Valid,
In addition to the great information that Ivan provided, I thought I would throw in some comments.
I wouldn't worry too much about the size. There are a number of variables that contribute to this.
On the config being used, am335x_evm, is will work for the SK. This config includes code into u-boot (and SPL, or MLO) that work for several boards. An EEPROM is read in the board.c file, and this ID information is used to know what code to call to initialize the specific board. So, one config can cover several boards and the EEPROM ID is used to program specific values, like DDR timing.
Hope this helps.
Hi Ivan,
I used the toolchain you suggested and it builds & runs fine thank you. I didn't try running the image created by the arago-2011.09 toolchain. The toolchain is under .../i686-arago-linux/... so is the Linaro GCC 2013.03 toolchain related in some way?
Hi RonB,
Thanks for your reply. I looked in AM335X-LINUX-PSP-04.06.00.08/src/u-boot/u-boot-04.06.00.08/arch/arm/lib/board.c (I think this is the file you refer to?) and ended up in AM335X-LINUX-PSP-04.06.00.08/src/u-boot/u-boot-04.06.00.08/board/ti/am335x/evm.c. I didn't realise the EVM and SK had I2C eeproms to identift themselves. I guess our product prototype doesn't have that, which I suppose I could use to identify it as a default?
Valid,
You certainly don't have to have the eeprom id, and many don't implement it at all. It makes it simpler for us to support many different boards with the same package. If you don't need this capability, they simply removing the appropriate logic from the board.c file is the right way to go.