GPIO pin 53 and 54 in u-boot

Hi Terje,

If pin numbering = 32*(<block number> + 1) + <block pin number>,

this should correspond to GPIO0_21 (MII1_TXD1) and GPIO0_22 (EHRPWM2A) which make no sense.

Sorry, I'm not able understand your question,

If I correctly understand your question, You don't know how GPIO 53 and 54 pins are derived.

pin numbering = 32 * <block number> + <block pin number>,

For GPIO1_21 (GPIO bank 0 and pin 20):

53 = 32*1 + 21

For GPIO1_22 (GPIO bank 0 and pin 21):

54 = 32*1 + 22

If this not answered your question, Please elaborate your question.

Dear Titus S

My problem is that u-boot refers two GPIO pins that is not documented in any manual and I try to find their possible function without having to analyze the u-boot source code.

The GPIO numbering referred to by u-boot is nowhere to be found int the schematics or in the Sitara datasheets. However I found a port/pin formula at probotix.com.

If the formula is correct, then the GPIO 53/54 corresponds to the Sitara GPIO0_21/22 (i.e. MII1_TXD1/EHRPWM2A)

Question: What does u-boot want to obtain by reading these pins?

Best regards

Terje

Hi Terje,

Question: What does u-boot want to obtain by reading these pins?

Where did you download this u-boot source code ?

This seems to be th prints are printed for debug purposes by some developers.

I hope it is not TI released SDK,

Dear Titus S,

I have not downloaded the source code yet.

The code that executes is the original Angstrom code delivered with the BBB.

The "Bone-debian-7.5-2014-05-14-2gb.img" downloaded and flashed to a uSD-Card shows exactly the same reading of the GPIO pin 53 and 54.

I am heading for source code downloading now. I seem to me that I have to dig down into the source code to find the answer. But since no one seem to know, the reading of the GPIO pins might be a "left-over" from some u-boot code written for another board.

So, if I download the code, I suspect that I might not find any code referering to these pins at all.

Best regards

Terje Froysa

Hi,

Sorry, I'm not sure for angstrom pre-built binaries,

Please try to download SDK from TI,

http://software-dl.ti.com/sitara_linux/esd/AM335xSDK/latest/index_FDS.html

We will assist you if you have any issues with TI pre-built.

Hi Titus,

Thanks for your concious replies!

I have now installed the ti-sdk-am335x-evm-07.00.00.00.

I will get back to you when having compiled and tested a new u-boot and kernel.

I'm a bit bewildered in my choises of sw tools.

The SDK is Yocto bitbake compliant (have used that in Gumstix project). However, the TI lectures are either CCS based or Linaro based tool chain (pure make).

What approach would you reccomend?

Best regards
Terje

Hi Terje,

Always we would recommend to use what TI documented,

Please follow as TI wikis mentioned.

My opinion is linaro based tool chain.

Please refer the quick start guide, getting start guide etc., in the above link.

Thanks Titus,

I'll try the (to-the-bone make method :-) Linaro tool chain and lectures.

Just a new observation:
(by erasing the MLO+u-boot on the uSD-Card FAT and experimenting with the uEnv.txt and zImage)

1. The MLO/u-boot never runs from the uSD-Card, but from the on-board FLASH (regardless of boot-button).
2. The uEnv.txt + zImage however, is sourced by the uSD-Card when inserted (regardless of the boot-button).

Hence, my assumptions were wrong regarding the MLO/u-boot code. 
My MLO/u-boot observations have always been from the prebuildt BBB out-of-the-box (Angstrom) environment.
Then, since I have never seen my copy of MLO/u-boot running, I can't trust the code for overwriting the existing onboard FLASH.

Do you see any way I can test-run an alternative MLO/u-boot code before copying it to the onboardFLASH?

Best regards
Terje

Hi,

Right now, I don't have this board with me,

Miroslav would support for this in http://e2e.ti.com/support/embedded/linux/f/354/t/356098.aspx this forum.

Hello again Titus,

I took the chance downloading the BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.

It seemed to install correctly in the eMMC environment.

Now, when booting the board without a uSD-Card inserted, I get a debian system booted (see listing below),
but the debian u-boot reports even more GPIO pins than in the anstrom environment:

1. pin 53 (i.e. GPIO0_21) connecting MII1_TXD1 in BBB schematics.
2. pin 54 (i.e. GPIO0_22) connecting EHRPWM2A in BBB schematics.
3. pin 55 (i.e. GPIO0_23) connecting EHRPWM2B in BBB schematics.
4. pin 56 (i.e. GPIO0_24) which is not a defined Sitara GPIO pin.

Hence, the u-boot in both the angstrom and the debian environment both read some GPIO pins not documented in the reference manual.

Can anyone explain the purpose and use of these pins in the u-boot environment?

Best regards
Terje Froysa

Boot listing:

U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)

I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  1 [08][08][08] 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
mmc0(part 0) is current device
Card did not respond to voltage select!
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 1
reading uEnv.txt
1699 bytes read in 7 ms (236.3 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
reading zImage
4103240 bytes read in 272 ms (14.4 MiB/s)
reading initrd.img
2952619 bytes read in 169 ms (16.7 MiB/s)
reading /dtbs/am335x-boneblack.dtb
25926 bytes read in 12 ms (2.1 MiB/s)
Kernel image @ 0x82000000 [ 0x000000 - 0x3e9c48 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Using Device Tree in place at 88000000, end 88009545

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.378241] omap2_mbox_probe: platform not supported
[    0.532811] tps65217-bl tps65217-bl: no platform data provided
[    0.596661] bone-capemgr bone_capemgr.9: slot #0: No cape found
[    0.633768] bone-capemgr bone_capemgr.9: slot #1: No cape found
[    0.670876] bone-capemgr bone_capemgr.9: slot #2: No cape found
[    0.707986] bone-capemgr bone_capemgr.9: slot #3: No cape found
[    0.722646] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)
[    0.732257] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[    0.739006] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    0.756539] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed
[    0.819581] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[    0.831300] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    0.838590] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
Loading, please wait...
Scanning for Btrfs filesystems
systemd-fsck[205]: rootfs: clean, 78769/111104 files, 390949/444160 blocks

Debian GNU/Linux 7 beaglebone ttyO0

default username:password is [debian:temppwd]

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

The IP Address for usb0 is: 192.168.7.2
beaglebone login: [   25.165636] libphy: PHY 4a101000.mdio:01 not found
[   25.170912] net eth0: phy 4a101000.mdio:01 not found on slave 1

Hi Terji,

Sorry, I'm not sure that why they are reading those GPIO values.

Have you tried to boot the pre-built executables from TI SDK ?

Hi Titus,

Thanks for your quick reply!

I tried to copy and rename the files from the SDK prebuilt-images to the boot directory (FAT partition).

I copied and renamed:

-rwxr-xr-x 1 124 3204  107920 Mar 30 19:37 MLO-am335x-evm
-rwxr-xr-x 1 124 3204  389768 Mar 30 19:37 u-boot-am335x-evm.img
-rw-r--r-- 1 124 3204 4117616 Mar 30 19:37 zImage-am335x-evm.bin
And renamed them to MLO, u-image and zImage

I didn't copy the dtb and the uEnv.txt though, since I beleaved them to be quite similar.

I ended with a broken boot....

Should I rader have copied the:
-rwxr-xr-x 1 124 3204  107400 Mar 30 19:37 u-boot-spl.bin-am335x-evm
And renamed it to MLO?

The board did not boot the uSD-Card either in this condition, so I'm reflashing the eMMC.

Best regards
Terje

Broken boot:

U-Boot SPL 2013.10-g78d8ebd (Mar 30 2014 - 20:46:34)
reading args
spl: error reading image args, err - -1
reading u-boot.img
spl: error reading image u-boot.img, err - 0
### ERROR ### Please RESET the board ###
[00][00]:[00]
U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img

From prebuilt images SDK version 7.0:

terjef@ubuntu:/home/sitara/ti-sdk-am335x-evm-07.00.00.00/board-support/prebuilt-images$ ll
total 4784
-rw-r--r-- 1 124 3204   34352 Mar 30 19:37 am335x-boneblack.dtb
-rw-r--r-- 1 124 3204   33206 Mar 30 19:37 am335x-bone.dtb
-rw-r--r-- 1 124 3204   41564 Mar 30 19:37 am335x-evm.dtb
-rw-r--r-- 1 124 3204   38048 Mar 30 19:37 am335x-evmsk.dtb
-rwxr-xr-x 1 124 3204  107920 Mar 30 19:37 MLO-am335x-evm
-rw-r--r-- 1 124 3204    1164 Mar 30 18:46 README
-rwxr-xr-x 1 124 3204  389768 Mar 30 19:37 u-boot-am335x-evm.img
-rwxr-xr-x 1 124 3204  107400 Mar 30 19:37 u-boot-spl.bin-am335x-evm
-rw-r--r-- 1 124 3204 4117616 Mar 30 19:37 zImage-am335x-evm.bin
terjef@ubuntu:/home/sitara/ti-sdk-am335x-evm-07.00.00.00/board-support/prebuilt-images$

By default the boot loaders are read from the first FAT partition, which is
usually called the "boot" partition.  Then the bootloader will look for the
uImage and DTB files in the /boot directory of the EXT partition, which is
usually called the "rootfs" partition.
terjef@ubuntu:/home/sitara/ti-sdk-am335x-evm-07.00.00.00/board-support/prebuilt-images$ more README

The files contained in this directory represent the images that were built
as part of the original SDK build and packaging process.  They are meant
to serve as a restore and starting point for your development.  In order
to use these images with an SD card they should be placed in the appropriate
locations.

By default these locations are:

================================================================================
|       FILE       |                  LOCATION                                 |
================================================================================
|    MLO           | boot partition
|    u-boot.img    | boot partition
|    uEnv.txt      | boot partition
|    uImage        | /boot directory of the rootfs partition
|    *.dtb         | /boot directory of the rootfs partition
================================================================================

By default the boot loaders are read from the first FAT partition, which is
usually called the "boot" partition.  Then the bootloader will look for the
uImage and DTB files in the /boot directory of the EXT partition, which is
usually called the "rootfs" partition.
terjef@ubuntu:/home/sitara/ti-sdk-am335x-evm-07.00.00.00/board-support/prebuilt-images$

Well,

I tried to copy the u-boot-spl.bin-am335x-evm and rename it to MLO, but no success.

Now the BBB didn't even produce an error message...

Best regards
Terje

You should not rename the .bin file to MLO. the .bin file is a flat binary file while the MLO is the .bin with a header attached. The boot ROM reads the header to determine where to load the binary data into internal RAM.

Steve K.

Hi Steve,

Thanks for your reply. The renaming of the .bin file was an experiment in lack of other good ideas.

I'm a bit out of ideas since even the prebuildt images of SDK 7.0 won't work.
I tried to build a u-boot by the SDK "make u-boot-spl" and copy the MLO and u-boot from the board-support.

The Rules.make file looked correct and the make succeeded. The code executed, but there was obviously a lot of discrepancies introduced by this.

I try to follow the do's and dont's found on the TI wiki, but theese recipes leaves little fundamental understanding of the u-boot process and its prerequisites. Many lectures are outdated, others are immature (like the "Sitara Linux u-boot" link in the "Sitara Linux SDK Getting Started Guide").
I must have browsed some 100 recipes, lectures and videos but they don't add up to unified understanding. They put me off in many directions that ends in blind tracks.

This is like the saying from 1980's: "Manuals.... which manuals? This is Unix my son.. you gotta know!!" and
"May the source be with you".. Well studying the source code is the safest, but last resort.

I am in a UAV-project trying to use a BBB for real-time programming and we need a good grasp on Linux.
If I am to copile a u-boot and Linux environment of my own in the SDK 7.0, can anybody reccomend a non-fragmented lecture that will reveal all prerequisites of the making?

Is it reccomendable rather using the mature SDK 6.0?

Best regards
Terje

My 2 cents. I am puzzled about your interpretation of the pin numbers 53-56. My guess would be more along these lines:

pin 53 = GPIO1_21 -> USR0(LED)
pin 54 = GPIO1_22 -> USR1(LED)
pin 55 = GPIO1_23 -> USR2(LED)
pin 56 = GPIO1_24 -> USR3(LED)

It would appear that somebody has some debug printing that is checking the level of the LEDs and they forgot to remove them before releasing the images. That sounds odd but from what have seen in the BBB world, an ad-hoc release seems common.

I've been watchng a co-worker deal with the Beagle Bone Black platform. I don't think you can treat a BBB like a TI AM335X EVM. The BBB is based upon mainline kernel GIT with patches from the beagleboard GIT. The TI AM335X EVM appears to use the kernel from TI's Arago GIT or prebuilt into the SDKs. My co-worker has using the following link with some succcess:
https://eewiki.net/display/linuxonarm/BeagleBone+Black

Hi Terje,

Thanks for your update.

Terje Froysa said:

The only guideline I have had regarding the pin 5x numbering is the formula:

pin=32*(<block number> +1)+<block pin no>

The pin number to bank /gpio mapping depends on the driver code. In u-boot and linux, it is zero based. I vaguely remember BIOSPSP and a table in the TRM is one based. That may be where the confusion came from.

Hi Norman,

Thanks again for your enlightening comments!

Yes, you are absolutely right. And with the timely words about the pin numbering, it all came to a sensible conclusion.
As long as the pin mapping was uncertain, I couldn't rule out that the gpio pin readings were ment to influence the boot process. Now I can rest my case and ignore the gpio reading reports.

Thank you!

Best regards
Terje Froysa