BBB + uboot 2014.07 - not booting

BBB + uboot 2014.07 - not booting

[Maciej Borzecki]

Hi all,

There seems to be a problem booting BBB from SD card with uboot 2014.07 from 
meta-ti, 2013.07 from yocto seems to work.
The card is partitioned as follows:

Device         Boot     Start       End Blocks  Id System
/dev/mmcblk0p1 *         2048     22527  10240   c W95 FAT32 (LBA)
/dev/mmcblk0p2          22528    227327 102400  83 Linux

I've already tried different cards.

This is all I get on the serial console:

U-Boot SPL 2014.07 (Aug 19 2014 - 10:45:01)
MMC: block number 0x100 exceeds max(0x0)
MMC: block number 0x200 exceeds max(0x0)
*** Error - No Valid Environment Area found
Using default environment

MMC: block number 0x1 exceeds max(0x0)
** Can't read partition table on 0:0 **
** Partition 1 not valid on device 0 **
spl_register_fat_device: fat register err - -1
### ERROR ### Please RESET the board ###

-- 

Maciej Borzęcki 
Senior Software Engineer Open-RnD Sp. z o.o. 
www.open-rnd.pl, Facebook, Twitter 
mobile: +48 telefon, fax: +48 42 657 9079 

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub 
poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do 
których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo 
zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku 
uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie 
nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. 

This message, including any attachments hereto, may contain privileged or 
confidential information and is sent solely for the attention and use of the 
intended addressee(s). If you are not an intended addressee, you may neither 
use this message nor copy or deliver it to anyone. In such case, you should 
immediately destroy this message and kindly notify the sender by reply email. 
Thank you.

Re: BBB + uboot 2014.07 - not booting

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

Maciej,

On Tue, Aug 19, 2014 at 6:29 AM, Maciej Borzecki <
maciej.borzecki@open-rnd.pl> wrote:

> Hi all,
>
> There seems to be a problem booting BBB from SD card with uboot 2014.07
> from
> meta-ti, 2013.07 from yocto seems to work.
> The card is partitioned as follows:
>
> Device         Boot     Start       End Blocks  Id System
> /dev/mmcblk0p1 *         2048     22527 10240   c W95 FAT32 (LBA)
> /dev/mmcblk0p2          22528    227327 102400  83 Linux
>
> I've already tried different cards.
>
> This is all I get on the serial console:
>
> U-Boot SPL 2014.07 (Aug 19 2014 - 10:45:01)
> MMC: block number 0x100 exceeds max(0x0)
> MMC: block number 0x200 exceeds max(0x0)
> *** Error - No Valid Environment Area found
> Using default environment
>
> MMC: block number 0x1 exceeds max(0x0)
> ** Can't read partition table on 0:0 **
> ** Partition 1 not valid on device 0 **
> spl_register_fat_device: fat register err - -1
> ### ERROR ### Please RESET the board ###
>
> --
>

I don't have this issue on SD card, bug I'm facing with another error when
MLO is installed on eMMC. This is my error message:

U-Boot SPL 2014.07 (Aug 13 2014 - 08:23:53)
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
spl: mmc init failed: err - -19
### ERROR ### Please RESET the board ###

Anyone have tested the MLO on eMMC?


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 2615 bytes --]

Re: BBB + uboot 2014.07 - not booting

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On Tue, Aug 19, 2014 at 11:39 AM, Diego Sueiro <diego.sueiro@gmail.com>
wrote:

>
> I don't have this issue on SD card, bug I'm facing with another error when
> MLO is installed on eMMC. This is my error message:
>
> U-Boot SPL 2014.07 (Aug 13 2014 - 08:23:53)
> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> spl: mmc init failed: err - -19
>  ### ERROR ### Please RESET the board ###
>
> Anyone have tested the MLO on eMMC?
>

I did some tests using yocto and meta-ti on daisy branch (beaglebone black)
using u-boot_2014.07.bb (upstream) and u-boot-ti-staging_2014.07.bb
recipes. And the results:

   - u-boot_2014.07: MLO works on SDcard and eMMC(2GB)
   - u-boot-ti-staging: MLO works on eMMC(2GB), but fails on SDcard

I did not tracked the differences yet.

Could someone test the MLO on eMMC for u-boot-ti-staging(v2014.07)?


Regards,


--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 2288 bytes --]

Re: BBB + uboot 2014.07 - not booting

[Cooper Jr., Franklin]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]



From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] On Behalf Of Diego Sueiro
Sent: Tuesday, August 19, 2014 3:00 PM
To: Maciej Borzecki
Cc: meta-ti mailing list
Subject: Re: [meta-ti] BBB + uboot 2014.07 - not booting


On Tue, Aug 19, 2014 at 11:39 AM, Diego Sueiro <diego.sueiro@gmail.com<mailto:diego.sueiro@gmail.com>> wrote:

I don't have this issue on SD card, bug I'm facing with another error when MLO is installed on eMMC. This is my error message:
U-Boot SPL 2014.07 (Aug 13 2014 - 08:23:53)
omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
spl: mmc init failed: err - -19
### ERROR ### Please RESET the board ###

Anyone have tested the MLO on eMMC?

I did some tests using yocto and meta-ti on daisy branch (beaglebone black) using u-boot_2014.07.bb<http://u-boot_2014.07.bb> (upstream) and u-boot-ti-staging_2014.07.bb<http://u-boot-ti-staging_2014.07.bb> recipes. And the results:

  *   u-boot_2014.07: MLO works on SDcard and eMMC(2GB)
  *   u-boot-ti-staging: MLO works on eMMC(2GB), but fails on SDcard
I did not tracked the differences yet.

Could someone test the MLO on eMMC for u-boot-ti-staging(v2014.07)?
[Franklin] I just booted up the board and it worked fine for me on the SD Card. I am however using a slightly newer commit "8bd803d2c552f5f85a79b4bfed7b322fbaf89e27" which is the latest commit on that branch.

Give that one a shot and see if it works for you.


Regards,


--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 8589 bytes --]

Re: BBB + uboot 2014.07 - not booting

[Peter A. Bigot]

I am seeing the same behavior with an SD card with u-boot from current 
meta-ti master (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)

I partition the cards and create the boot/root partitions with:

sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
( echo ,9,0x0C,* ; echo ,,,- ) \
   | sudo sfdisk -D -H 255 -S 63 ${MMC}

${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2

${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot

This process works with poky master and yocto-bsp on beaglebone.

I recall from long ago that some TI systems were picky about the 
partitioning of the boot media.  Would somebody with an SD card image 
that boots the current meta-ti master provide the output of fdisk -lu 
from it, or a pointer to instructions for doing the formatting?  For 
reference, what doesn't work is:

llc[325]$ sudo fdisk -lu /dev/sdh

Disk /dev/sdh: 7892 MB, 7892631552 bytes
255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

    Device Boot      Start         End      Blocks   Id  System
/dev/sdh1   *          63      144584       72261    c  W95 FAT32 (LBA)
/dev/sdh2          144585    15406334     7630875   83  Linux

Thanks.

Peter


On 08/19/2014 04:29 AM, Maciej Borzecki wrote:
> Hi all,
>
> There seems to be a problem booting BBB from SD card with uboot 2014.07 from
> meta-ti, 2013.07 from yocto seems to work.
> The card is partitioned as follows:
>
> Device         Boot     Start       End Blocks  Id System
> /dev/mmcblk0p1 *         2048     22527  10240   c W95 FAT32 (LBA)
> /dev/mmcblk0p2          22528    227327 102400  83 Linux
>
> I've already tried different cards.
>
> This is all I get on the serial console:
>
> U-Boot SPL 2014.07 (Aug 19 2014 - 10:45:01)
> MMC: block number 0x100 exceeds max(0x0)
> MMC: block number 0x200 exceeds max(0x0)
> *** Error - No Valid Environment Area found
> Using default environment
>
> MMC: block number 0x1 exceeds max(0x0)
> ** Can't read partition table on 0:0 **
> ** Partition 1 not valid on device 0 **
> spl_register_fat_device: fat register err - -1
> ### ERROR ### Please RESET the board ###
>

Re: BBB + uboot 2014.07 - not booting

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 2900 bytes --]

Peter,

On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com> wrote:

> I am seeing the same behavior with an SD card with u-boot from current
> meta-ti master (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
>
> I partition the cards and create the boot/root partitions with:
>
> sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
> ( echo ,9,0x0C,* ; echo ,,,- ) \
>   | sudo sfdisk -D -H 255 -S 63 ${MMC}
>
> ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
> ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
>
> ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
>
> This process works with poky master and yocto-bsp on beaglebone.
>
> I recall from long ago that some TI systems were picky about the
> partitioning of the boot media.
>

This is not true for recent Sitara SoCs:
http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088



> Would somebody with an SD card image that boots the current meta-ti master
> provide the output of fdisk -lu from it, or a pointer to instructions for
> doing the formatting?  For reference, what doesn't work is:
>
> llc[325]$ sudo fdisk -lu /dev/sdh
>
> Disk /dev/sdh: 7892 MB, 7892631552 bytes
> 255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdh1   *          63      144584       72261    c  W95 FAT32 (LBA)
> /dev/sdh2          144585    15406334     7630875   83  Linux
>

I'm using the following partition layout (both working on eMMC and sdcard
with u-boot_2014.07.bb):

# fdisk -lu /dev/mmcblk0

Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *          63       80324       40131    c  W95 FAT32 (LBA)
/dev/mmcblk0p2           80325     1558304      738990   83  Linux
/dev/mmcblk0p3         1558305     3036284      738990   83  Linux
/dev/mmcblk0p4         3036285     3743144      353430    5  Extended
/dev/mmcblk0p5         3036348     3068414       16033+  83  Linux
/dev/mmcblk0p6         3068478     3743144      337333+  83  Linux


With u-boot-ti-staging_2014.07.bb I just can boot from sdcard.
I'm using daisy branch, meta-linaro-toolchain with gcc 4.8.

Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 5295 bytes --]

Re: BBB + uboot 2014.07 - not booting

[Peter A. Bigot]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

On 09/01/2014 04:53 PM, Diego Sueiro wrote:
> Peter,
>
> On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com 
> <mailto:pab@pabigot.com>> wrote:
>
>     I am seeing the same behavior with an SD card with u-boot from
>     current meta-ti master
>     (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
>
>     I partition the cards and create the boot/root partitions with:
>
>     sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
>     ( echo ,9,0x0C,* ; echo ,,,- ) \
>       | sudo sfdisk -D -H 255 -S 63 ${MMC}
>
>     ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
>     ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
>
>     ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
>
>     This process works with poky master and yocto-bsp on beaglebone.
>
>     I recall from long ago that some TI systems were picky about the
>     partitioning of the boot media.
>
>
> This is not true for recent Sitara SoCs:
> http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088
>
>     Would somebody with an SD card image that boots the current
>     meta-ti master provide the output of fdisk -lu from it, or a
>     pointer to instructions for doing the formatting?  For reference,
>     what doesn't work is:
>
>     llc[325]$ sudo fdisk -lu /dev/sdh
>
>     Disk /dev/sdh: 7892 MB, 7892631552 bytes
>     255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
>     Units = sectors of 1 * 512 = 512 bytes
>     Sector size (logical/physical): 512 bytes / 512 bytes
>     I/O size (minimum/optimal): 512 bytes / 512 bytes
>     Disk identifier: 0x00000000
>
>
>        Device Boot      Start         End      Blocks  Id  System
>     /dev/sdh1   *          63      144584       72261    c W95 FAT32 (LBA)
>     /dev/sdh2          144585    15406334     7630875   83 Linux
>
>
> I'm using the following partition layout (both working on eMMC and 
> sdcard with u-boot_2014.07.bb <http://u-boot_2014.07.bb>):
>
>     # fdisk -lu /dev/mmcblk0
>
>     Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
>     Units = sectors of 1 * 512 = 512 bytes
>     Sector size (logical/physical): 512 bytes / 512 bytes
>     I/O size (minimum/optimal): 512 bytes / 512 bytes
>     Disk label type: dos
>     Disk identifier: 0x00000000
>
>             Device Boot      Start     End      Blocks   Id  System
>     /dev/mmcblk0p1   *          63   80324       40131    c  W95 FAT32
>     (LBA)
>

Thanks.  That does appear to be an eMMC partition, which probably 
shouldn't matter, but I replicated the configuration on a 2GB class 4 
uSD card, and an 8GB class 6, and it doesn't work on either one.

llc[77]$ sudo fdisk -lu /dev/sdh

Disk /dev/sdh: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

    Device Boot      Start         End      Blocks   Id  System
/dev/sdh1   *          63       80324       40131    c  W95 FAT32 (LBA)
/dev/sdh2           80325     7743329     3831502+  83  Linux

Anybody got a uSD partition layout that works?  I'm suspecting an issue 
with the heads/sectors/cylinders configuration.

(FWIW: I'm also using u-boot-staging-ti, as that's the default for 
beaglebone on the master branch.)

Peter

[-- Attachment #2: Type: text/html, Size: 7347 bytes --]

Re: BBB + uboot 2014.07 - not booting

[Robert Nelson]

On Mon, Sep 1, 2014 at 6:28 PM, Peter A. Bigot <pab@pabigot.com> wrote:
> On 09/01/2014 04:53 PM, Diego Sueiro wrote:
>
> Peter,
>
> On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com> wrote:
>>
>> I am seeing the same behavior with an SD card with u-boot from current
>> meta-ti master (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
>>
>> I partition the cards and create the boot/root partitions with:
>>
>> sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
>> ( echo ,9,0x0C,* ; echo ,,,- ) \
>>   | sudo sfdisk -D -H 255 -S 63 ${MMC}
>>
>> ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
>> ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
>>
>> ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
>>
>> This process works with poky master and yocto-bsp on beaglebone.
>>
>> I recall from long ago that some TI systems were picky about the
>> partitioning of the boot media.
>
>
> This is not true for recent Sitara SoCs:
> http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088
>
>
>>
>> Would somebody with an SD card image that boots the current meta-ti master
>> provide the output of fdisk -lu from it, or a pointer to instructions for
>> doing the formatting?  For reference, what doesn't work is:
>>
>> llc[325]$ sudo fdisk -lu /dev/sdh
>>
>> Disk /dev/sdh: 7892 MB, 7892631552 bytes
>> 255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0x00000000
>>
>>
>>    Device Boot      Start         End      Blocks   Id  System
>> /dev/sdh1   *          63      144584       72261    c  W95 FAT32 (LBA)
>> /dev/sdh2          144585    15406334     7630875   83  Linux
>
>
> I'm using the following partition layout (both working on eMMC and sdcard
> with u-boot_2014.07.bb):
>
> # fdisk -lu /dev/mmcblk0
>
> Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk label type: dos
> Disk identifier: 0x00000000
>
>         Device Boot      Start         End      Blocks   Id  System
> /dev/mmcblk0p1   *          63       80324       40131    c  W95 FAT32 (LBA)
>
>
> Thanks.  That does appear to be an eMMC partition, which probably shouldn't
> matter, but I replicated the configuration on a 2GB class 4 uSD card, and an
> 8GB class 6, and it doesn't work on either one.
>
> llc[77]$ sudo fdisk -lu /dev/sdh
>
> Disk /dev/sdh: 3965 MB, 3965190144 bytes
> 255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
>
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdh1   *          63       80324       40131    c  W95 FAT32 (LBA)
> /dev/sdh2           80325     7743329     3831502+  83  Linux
>
> Anybody got a uSD partition layout that works?  I'm suspecting an issue with
> the heads/sectors/cylinders configuration.
>
> (FWIW: I'm also using u-boot-staging-ti, as that's the default for
> beaglebone on the master branch.)

You could bypass the whole fat partition (On omap4+ bootrom
generations (including the am335x)):

dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k

Just make sure to leave a 1mb hole when you create a partition for
everything else.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: BBB + uboot 2014.07 - not booting

[Peter A. Bigot]

On 08/19/2014 04:29 AM, Maciej Borzecki wrote:
> Hi all,
>
> There seems to be a problem booting BBB from SD card with uboot 2014.07 from
> meta-ti, 2013.07 from yocto seems to work.
> The card is partitioned as follows:
>
> Device         Boot     Start       End Blocks  Id System
> /dev/mmcblk0p1 *         2048     22527  10240   c W95 FAT32 (LBA)
> /dev/mmcblk0p2          22528    227327 102400  83 Linux
>
> I've already tried different cards.
>
> This is all I get on the serial console:
>
> U-Boot SPL 2014.07 (Aug 19 2014 - 10:45:01)
> MMC: block number 0x100 exceeds max(0x0)
> MMC: block number 0x200 exceeds max(0x0)
> *** Error - No Valid Environment Area found
> Using default environment
>
> MMC: block number 0x1 exceeds max(0x0)
> ** Can't read partition table on 0:0 **
> ** Partition 1 not valid on device 0 **
> spl_register_fat_device: fat register err - -1
> ### ERROR ### Please RESET the board ###

This is a bug in handling mmc_switch_part: what's happening is that the 
code reconfigures the mmc device to look at the partition on which the 
environment is to be found, but fails to restore it to reflect the state 
of the whole device.  I.e., the mmc capacity and lba are zero in my case 
(I have no partition 2 on the uSD card), but mmc_switch_part() returns 
-ENODEV on the attempt to switch back in fini_mmc_for_env() without also 
resetting the capacity to what the rest of the system expects.

I'll follow up here with a patch based on the ti-uboot repository. It 
conflicts with an upstream patch in u-boot master; I'll let Tom or 
somebody else sort that out.

Peter

[ti-uboot][PATCH] mmc: restore capacity when switching to partition 0

[Peter A. Bigot]

The capacity and lba for an MMC device with part_num 0 reflects the
whole device.  When mmc_switch_part() successfully switches to a
partition, the capacity is changed to that partition.  As partition 0
does not physically exist, attempts to switch back to the whole device
will indicate an error, but should still restore the capacity setting.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 drivers/mmc/mmc.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index b5477b1..b05c6ee 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -596,10 +596,11 @@ int mmc_switch_part(int dev_num, unsigned int part_num)
 	ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
 			 (mmc->part_config & ~PART_ACCESS_MASK)
 			 | (part_num & PART_ACCESS_MASK));
-	if (ret)
-		return ret;
 
-	return mmc_set_capacity(mmc, part_num);
+	if ((0 == ret) || ((-ENODEV == ret) && (0 == part_num)))
+		ret = mmc_set_capacity(mmc, part_num);
+
+	return ret;
 }
 
 int mmc_getcd(struct mmc *mmc)
-- 
1.8.5.5

Re: BBB + uboot 2014.07 - not booting

[Maciej Borzecki]

On Monday 01 of September 2014 18:28:14 Peter A. Bigot wrote:
> On 09/01/2014 04:53 PM, Diego Sueiro wrote:
> > Peter,
> > 
> > On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com
> > 
> > <mailto:pab@pabigot.com>> wrote:
> >     I am seeing the same behavior with an SD card with u-boot from
> >     current meta-ti master
> >     (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
> >     
> >     I partition the cards and create the boot/root partitions with:
> >     
> >     sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
> >     ( echo ,9,0x0C,* ; echo ,,,- ) \
> >     
> >       | sudo sfdisk -D -H 255 -S 63 ${MMC}
> >     
> >     ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
> >     ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
> >     
> >     ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
> >     
> >     This process works with poky master and yocto-bsp on beaglebone.
> >     
> >     I recall from long ago that some TI systems were picky about the
> >     partitioning of the boot media.
> > 
> > This is not true for recent Sitara SoCs:
> > http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088
> > 
> >     Would somebody with an SD card image that boots the current
> >     meta-ti master provide the output of fdisk -lu from it, or a
> >     pointer to instructions for doing the formatting?  For reference,
> >     what doesn't work is:
> >     
> >     llc[325]$ sudo fdisk -lu /dev/sdh
> >     
> >     Disk /dev/sdh: 7892 MB, 7892631552 bytes
> >     255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
> >     Units = sectors of 1 * 512 = 512 bytes
> >     Sector size (logical/physical): 512 bytes / 512 bytes
> >     I/O size (minimum/optimal): 512 bytes / 512 bytes
> >     Disk identifier: 0x00000000
> >     
> >        Device Boot      Start         End      Blocks  Id  System
> >     
> >     /dev/sdh1   *          63      144584       72261    c W95 FAT32 (LBA)
> >     /dev/sdh2          144585    15406334     7630875   83 Linux
> > 
> > I'm using the following partition layout (both working on eMMC and
> > 
> > sdcard with u-boot_2014.07.bb <http://u-boot_2014.07.bb>):
> >     # fdisk -lu /dev/mmcblk0
> >     
> >     Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
> >     Units = sectors of 1 * 512 = 512 bytes
> >     Sector size (logical/physical): 512 bytes / 512 bytes
> >     I/O size (minimum/optimal): 512 bytes / 512 bytes
> >     Disk label type: dos
> >     Disk identifier: 0x00000000
> >     
> >             Device Boot      Start     End      Blocks   Id  System
> >     
> >     /dev/mmcblk0p1   *          63   80324       40131    c  W95 FAT32
> >     (LBA)
> 
> Thanks.  That does appear to be an eMMC partition, which probably
> shouldn't matter, but I replicated the configuration on a 2GB class 4
> uSD card, and an 8GB class 6, and it doesn't work on either one.
> 
> llc[77]$ sudo fdisk -lu /dev/sdh
> 
> Disk /dev/sdh: 3965 MB, 3965190144 bytes
> 255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
> 
>     Device Boot      Start         End      Blocks   Id  System
> /dev/sdh1   *          63       80324       40131    c  W95 FAT32 (LBA)
> /dev/sdh2           80325     7743329     3831502+  83  Linux
> 
> Anybody got a uSD partition layout that works?  I'm suspecting an issue
> with the heads/sectors/cylinders configuration.

Try looking here:
http://article.gmane.org/gmane.linux.embedded.yocto.meta-ti/4371

Although I could not confirm this, it seems that the first partition on SD 
needs to have an even block count (not sure about eMMC though, but I'm 
guessing the same rules apply).

-- 

Maciej Borzęcki 
Senior Software Engineer Open-RnD Sp. z o.o. 
www.open-rnd.pl, Facebook, Twitter 
mobile: +48 telefon, fax: +48 42 657 9079 

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub 
poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do 
których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo 
zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku 
uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie 
nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. 

This message, including any attachments hereto, may contain privileged or 
confidential information and is sent solely for the attention and use of the 
intended addressee(s). If you are not an intended addressee, you may neither 
use this message nor copy or deliver it to anyone. In such case, you should 
immediately destroy this message and kindly notify the sender by reply email. 
Thank you.

Re: BBB + uboot 2014.07 - not booting

[Peter A. Bigot]

On 09/02/2014 02:56 AM, Maciej Borzecki wrote:
> On Monday 01 of September 2014 18:28:14 Peter A. Bigot wrote:
>> On 09/01/2014 04:53 PM, Diego Sueiro wrote:
>>> Peter,
>>>
>>> On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com
>>>
>>> <mailto:pab@pabigot.com>> wrote:
>>>      I am seeing the same behavior with an SD card with u-boot from
>>>      current meta-ti master
>>>      (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
>>>      
>>>      I partition the cards and create the boot/root partitions with:
>>>      
>>>      sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
>>>      ( echo ,9,0x0C,* ; echo ,,,- ) \
>>>      
>>>        | sudo sfdisk -D -H 255 -S 63 ${MMC}
>>>      
>>>      ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
>>>      ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
>>>      
>>>      ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
>>>      
>>>      This process works with poky master and yocto-bsp on beaglebone.
>>>      
>>>      I recall from long ago that some TI systems were picky about the
>>>      partitioning of the boot media.
>>>
>>> This is not true for recent Sitara SoCs:
>>> http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088
>>>
>>>      Would somebody with an SD card image that boots the current
>>>      meta-ti master provide the output of fdisk -lu from it, or a
>>>      pointer to instructions for doing the formatting?  For reference,
>>>      what doesn't work is:
>>>      
>>>      llc[325]$ sudo fdisk -lu /dev/sdh
>>>      
>>>      Disk /dev/sdh: 7892 MB, 7892631552 bytes
>>>      255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
>>>      Units = sectors of 1 * 512 = 512 bytes
>>>      Sector size (logical/physical): 512 bytes / 512 bytes
>>>      I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>      Disk identifier: 0x00000000
>>>      
>>>         Device Boot      Start         End      Blocks  Id  System
>>>      
>>>      /dev/sdh1   *          63      144584       72261    c W95 FAT32 (LBA)
>>>      /dev/sdh2          144585    15406334     7630875   83 Linux
>>>
>>> I'm using the following partition layout (both working on eMMC and
>>>
>>> sdcard with u-boot_2014.07.bb <http://u-boot_2014.07.bb>):
>>>      # fdisk -lu /dev/mmcblk0
>>>      
>>>      Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
>>>      Units = sectors of 1 * 512 = 512 bytes
>>>      Sector size (logical/physical): 512 bytes / 512 bytes
>>>      I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>      Disk label type: dos
>>>      Disk identifier: 0x00000000
>>>      
>>>              Device Boot      Start     End      Blocks   Id  System
>>>      
>>>      /dev/mmcblk0p1   *          63   80324       40131    c  W95 FAT32
>>>      (LBA)
>> Thanks.  That does appear to be an eMMC partition, which probably
>> shouldn't matter, but I replicated the configuration on a 2GB class 4
>> uSD card, and an 8GB class 6, and it doesn't work on either one.
>>
>> llc[77]$ sudo fdisk -lu /dev/sdh
>>
>> Disk /dev/sdh: 3965 MB, 3965190144 bytes
>> 255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0x00000000
>>
>>      Device Boot      Start         End      Blocks   Id  System
>> /dev/sdh1   *          63       80324       40131    c  W95 FAT32 (LBA)
>> /dev/sdh2           80325     7743329     3831502+  83  Linux
>>
>> Anybody got a uSD partition layout that works?  I'm suspecting an issue
>> with the heads/sectors/cylinders configuration.
> Try looking here:
> http://article.gmane.org/gmane.linux.embedded.yocto.meta-ti/4371
>
> Although I could not confirm this, it seems that the first partition on SD
> needs to have an even block count (not sure about eMMC though, but I'm
> guessing the same rules apply).

I had seen that, and did try even block counts, which didn't help. 
Please try applying the u-boot patch I sent to your build and seeing if 
that fixes the issue for you.  The symptoms you described fit it precisely.

It's not obvious whether the problem remains when the upstream changes 
to u-boot that conflict with it are present, but they're past 2014.07 so 
it'd be good to get that patch into meta-ti or the TI u-boot branch.  
I'd push it to OE Core but they're still at 2013.07 which doesn't have 
this problem.  If it also fixes the problems you and Diego are having 
that's more evidence it's worth adding.

Peter

Re: [ti-uboot][PATCH] mmc: restore capacity when switching to partition 0

[Tom Rini]

On Mon, Sep 01, 2014 at 10:11:30PM -0500, Peter A. Bigot wrote:

> The capacity and lba for an MMC device with part_num 0 reflects the
> whole device.  When mmc_switch_part() successfully switches to a
> partition, the capacity is changed to that partition.  As partition 0
> does not physically exist, attempts to switch back to the whole device
> will indicate an error, but should still restore the capacity setting.

In other words:
# mmc dev 0:1
...
# mmc dev 0:0

Fails?  And the following patch fixes it.

> 
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
>  drivers/mmc/mmc.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index b5477b1..b05c6ee 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -596,10 +596,11 @@ int mmc_switch_part(int dev_num, unsigned int part_num)
>  	ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
>  			 (mmc->part_config & ~PART_ACCESS_MASK)
>  			 | (part_num & PART_ACCESS_MASK));
> -	if (ret)
> -		return ret;
>  
> -	return mmc_set_capacity(mmc, part_num);
> +	if ((0 == ret) || ((-ENODEV == ret) && (0 == part_num)))

This is backwards from how we usually code things:

if ((ret == 0) || ((ret == -ENODEV) && (part_num == 0)))

And should have a comment above it that's a short summary of the commit
message so this doesn't get lost later on.

> +		ret = mmc_set_capacity(mmc, part_num);
> +
> +	return ret;
>  }
>  
>  int mmc_getcd(struct mmc *mmc)
> -- 
> 1.8.5.5
> 
> -- 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

And speaking of getting lost, this isn't the U-Boot mailing list so the
change would get lost with the next release.  Please make sure to post
the next version to the u-boot ML as well and CC Pantelis.   Thanks!

-- 
Tom

Re: [ti-uboot][PATCH] mmc: restore capacity when switching to partition 0

[Peter A. Bigot]

On 09/02/2014 11:44 AM, Tom Rini wrote:
> On Mon, Sep 01, 2014 at 10:11:30PM -0500, Peter A. Bigot wrote:
>
>> The capacity and lba for an MMC device with part_num 0 reflects the
>> whole device.  When mmc_switch_part() successfully switches to a
>> partition, the capacity is changed to that partition.  As partition 0
>> does not physically exist, attempts to switch back to the whole device
>> will indicate an error, but should still restore the capacity setting.
> In other words:
> # mmc dev 0:1
> ...
> # mmc dev 0:0
>
> Fails?

I don't know.  This error occurs in SPL mode where there is no command 
line and only one device.  From the companion email:

This is a bug in handling mmc_switch_part: what's happening is that the 
code reconfigures the mmc device to look at the partition on which the 
environment is to be found, but fails to restore it to reflect the state 
of the whole device. I.e., the mmc capacity and lba are zero in my case 
(I have no partition 2 on the uSD card), but mmc_switch_part() returns 
-ENODEV on the attempt to switch back in fini_mmc_for_env() without also 
resetting the capacity to what the rest of the system expects.

>   And the following patch fixes it.
>
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>>   drivers/mmc/mmc.c | 7 ++++---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index b5477b1..b05c6ee 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -596,10 +596,11 @@ int mmc_switch_part(int dev_num, unsigned int part_num)
>>   	ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
>>   			 (mmc->part_config & ~PART_ACCESS_MASK)
>>   			 | (part_num & PART_ACCESS_MASK));
>> -	if (ret)
>> -		return ret;
>>   
>> -	return mmc_set_capacity(mmc, part_num);
>> +	if ((0 == ret) || ((-ENODEV == ret) && (0 == part_num)))

Yes.  There are several ways to fix it; this is the one with the minimal 
change from existing behavior.  (It is necessary to try the mmc_switch() 
call even if part_num is zero since that resets some internal driver state.)

> This is backwards from how we usually code things:
>
> if ((ret == 0) || ((ret == -ENODEV) && (part_num == 0)))

OK; I default to yoda conditions since it saves me at least once a year, 
but can swap things back around.  No objection to explicit 
parenthesization (the GNU folks hate it).

> And should have a comment above it that's a short summary of the commit
> message so this doesn't get lost later on.

OK.

>
>> +		ret = mmc_set_capacity(mmc, part_num);
>> +
>> +	return ret;
>>   }
>>   
>>   int mmc_getcd(struct mmc *mmc)
>> -- 
>> 1.8.5.5
>>
>> -- 
>> _______________________________________________
>> meta-ti mailing list
>> meta-ti@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-ti

If I update this patch, will you see the patch gets into ti-uboot?

> And speaking of getting lost, this isn't the U-Boot mailing list so the
> change would get lost with the next release.  Please make sure to post
> the next version to the u-boot ML as well and CC Pantelis.   Thanks!

This fix is specific to 2014.07, and may or may not also be influenced 
by TI-specific patches.  AFAICT u-boot doesn't maintain a stable-release 
patch branch.

I mentioned in deleted material that subsequent changes rework how the 
environment code manipulates the mmc device so it doesn't apply to 
u-boot master.  There are several such changes that are cumulative, so 
there's some rework to be done.  I'd have to switch over to using u-boot 
master to see if the problem still remains in the current 
implementation.  At this time that's not in scope for me.

Peter

Re: [ti-uboot][PATCH] mmc: restore capacity when switching to partition 0

[Tom Rini]

On Tue, Sep 02, 2014 at 12:00:49PM -0500, Peter A. Bigot wrote:
> On 09/02/2014 11:44 AM, Tom Rini wrote:
> >On Mon, Sep 01, 2014 at 10:11:30PM -0500, Peter A. Bigot wrote:
> >
> >>The capacity and lba for an MMC device with part_num 0 reflects the
> >>whole device.  When mmc_switch_part() successfully switches to a
> >>partition, the capacity is changed to that partition.  As partition 0
> >>does not physically exist, attempts to switch back to the whole device
> >>will indicate an error, but should still restore the capacity setting.
> >In other words:
> ># mmc dev 0:1
> >...
> ># mmc dev 0:0
> >
> >Fails?
> 
> I don't know.  This error occurs in SPL mode where there is no
> command line and only one device.  From the companion email:
> 
> This is a bug in handling mmc_switch_part: what's happening is that
> the code reconfigures the mmc device to look at the partition on
> which the environment is to be found, but fails to restore it to
> reflect the state of the whole device. I.e., the mmc capacity and
> lba are zero in my case (I have no partition 2 on the uSD card), but
> mmc_switch_part() returns -ENODEV on the attempt to switch back in
> fini_mmc_for_env() without also resetting the capacity to what the
> rest of the system expects.

OK.

> >  And the following patch fixes it.
> >
> >>Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> >>---
> >>  drivers/mmc/mmc.c | 7 ++++---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >>index b5477b1..b05c6ee 100644
> >>--- a/drivers/mmc/mmc.c
> >>+++ b/drivers/mmc/mmc.c
> >>@@ -596,10 +596,11 @@ int mmc_switch_part(int dev_num, unsigned int part_num)
> >>  	ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
> >>  			 (mmc->part_config & ~PART_ACCESS_MASK)
> >>  			 | (part_num & PART_ACCESS_MASK));
> >>-	if (ret)
> >>-		return ret;
> >>-	return mmc_set_capacity(mmc, part_num);
> >>+	if ((0 == ret) || ((-ENODEV == ret) && (0 == part_num)))
> 
> Yes.  There are several ways to fix it; this is the one with the
> minimal change from existing behavior.  (It is necessary to try the
> mmc_switch() call even if part_num is zero since that resets some
> internal driver state.)
> 
> >This is backwards from how we usually code things:
> >
> >if ((ret == 0) || ((ret == -ENODEV) && (part_num == 0)))
> 
> OK; I default to yoda conditions since it saves me at least once a
> year, but can swap things back around.  No objection to explicit
> parenthesization (the GNU folks hate it).
> 
> >And should have a comment above it that's a short summary of the commit
> >message so this doesn't get lost later on.
> 
> OK.
> 
> >
> >>+		ret = mmc_set_capacity(mmc, part_num);
> >>+
> >>+	return ret;
> >>  }
> >>  int mmc_getcd(struct mmc *mmc)
> >>-- 
> >>1.8.5.5
> >>
> >>-- 
> >>_______________________________________________
> >>meta-ti mailing list
> >>meta-ti@yoctoproject.org
> >>https://lists.yoctoproject.org/listinfo/meta-ti
> 
> If I update this patch, will you see the patch gets into ti-uboot?

This is probably "good enough" for meta-ti, especially if you get it
into mainline as it could be in v2014.10.

> >And speaking of getting lost, this isn't the U-Boot mailing list so the
> >change would get lost with the next release.  Please make sure to post
> >the next version to the u-boot ML as well and CC Pantelis.   Thanks!
> 
> This fix is specific to 2014.07, and may or may not also be
> influenced by TI-specific patches.  AFAICT u-boot doesn't maintain a
> stable-release patch branch.
> 
> I mentioned in deleted material that subsequent changes rework how
> the environment code manipulates the mmc device so it doesn't apply
> to u-boot master.  There are several such changes that are
> cumulative, so there's some rework to be done.  I'd have to switch
> over to using u-boot master to see if the problem still remains in
> the current implementation.  At this time that's not in scope for
> me.

Well, Pantelis?  How does this all look when compared with master?

-- 
Tom

Re: [ti-uboot][PATCH] mmc: restore capacity when switching to partition 0

[Peter A. Bigot]

On 09/02/2014 05:01 PM, Tom Rini wrote:
> On Tue, Sep 02, 2014 at 12:00:49PM -0500, Peter A. Bigot wrote:
>>
>> If I update this patch, will you see the patch gets into ti-uboot?
> This is probably "good enough" for meta-ti, especially if you get it
> into mainline as it could be in v2014.10.

If the existing patch is ok for you to put into ti-uboot I won't rework 
it.  Thanks.

I've verified the problem does exist in 2014.10-rc2 and will prepare a 
patch and submit it upstream.

Peter

Re: BBB + uboot 2014.07 - not booting

[Maciej Borzecki]

On Tuesday 02 of September 2014 06:42:11 Peter A. Bigot wrote:
> On 09/02/2014 02:56 AM, Maciej Borzecki wrote:
> > On Monday 01 of September 2014 18:28:14 Peter A. Bigot wrote:
> >> On 09/01/2014 04:53 PM, Diego Sueiro wrote:
> >>> Peter,
> >>> 
> >>> On Mon, Sep 1, 2014 at 6:10 PM, Peter A. Bigot <pab@pabigot.com
> >>> 
> >>> <mailto:pab@pabigot.com>> wrote:
> >>>      I am seeing the same behavior with an SD card with u-boot from
> >>>      current meta-ti master
> >>>      (MLO-beaglebone-2014.07-r1+gitrAUTOINC+8bd803d2c5)
> >>>      
> >>>      I partition the cards and create the boot/root partitions with:
> >>>      
> >>>      sudo dd if=/dev/zero of=${MMC} bs=1024 count=1024
> >>>      ( echo ,9,0x0C,* ; echo ,,,- ) \
> >>>      
> >>>        | sudo sfdisk -D -H 255 -S 63 ${MMC}
> >>>      
> >>>      ${SUDO} mkfs.vfat -F 16 -n boot ${MMC}1
> >>>      ${SUDO} mkfs -t ${FSTYPE} -L rootfs ${MMC}2
> >>>      
> >>>      ${SUDO} cp -p MLO u-boot.img ${MPROOT}/boot
> >>>      
> >>>      This process works with poky master and yocto-bsp on beaglebone.
> >>>      
> >>>      I recall from long ago that some TI systems were picky about the
> >>>      partitioning of the boot media.
> >>> 
> >>> This is not true for recent Sitara SoCs:
> >>> http://permalink.gmane.org/gmane.comp.handhelds.openembedded/64088
> >>> 
> >>>      Would somebody with an SD card image that boots the current
> >>>      meta-ti master provide the output of fdisk -lu from it, or a
> >>>      pointer to instructions for doing the formatting?  For reference,
> >>>      what doesn't work is:
> >>>      
> >>>      llc[325]$ sudo fdisk -lu /dev/sdh
> >>>      
> >>>      Disk /dev/sdh: 7892 MB, 7892631552 bytes
> >>>      255 heads, 63 sectors/track, 959 cylinders, total 15415296 sectors
> >>>      Units = sectors of 1 * 512 = 512 bytes
> >>>      Sector size (logical/physical): 512 bytes / 512 bytes
> >>>      I/O size (minimum/optimal): 512 bytes / 512 bytes
> >>>      Disk identifier: 0x00000000
> >>>      
> >>>         Device Boot      Start         End      Blocks  Id  System
> >>>      
> >>>      /dev/sdh1   *          63      144584       72261    c W95 FAT32
> >>>      (LBA)
> >>>      /dev/sdh2          144585    15406334     7630875   83 Linux
> >>> 
> >>> I'm using the following partition layout (both working on eMMC and
> >>> 
> >>> sdcard with u-boot_2014.07.bb <http://u-boot_2014.07.bb>):
> >>>      # fdisk -lu /dev/mmcblk0
> >>>      
> >>>      Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes, 3751936 sectors
> >>>      Units = sectors of 1 * 512 = 512 bytes
> >>>      Sector size (logical/physical): 512 bytes / 512 bytes
> >>>      I/O size (minimum/optimal): 512 bytes / 512 bytes
> >>>      Disk label type: dos
> >>>      Disk identifier: 0x00000000
> >>>      
> >>>              Device Boot      Start     End      Blocks   Id  System
> >>>      
> >>>      /dev/mmcblk0p1   *          63   80324       40131    c  W95 FAT32
> >>>      (LBA)
> >> 
> >> Thanks.  That does appear to be an eMMC partition, which probably
> >> shouldn't matter, but I replicated the configuration on a 2GB class 4
> >> uSD card, and an 8GB class 6, and it doesn't work on either one.
> >> 
> >> llc[77]$ sudo fdisk -lu /dev/sdh
> >> 
> >> Disk /dev/sdh: 3965 MB, 3965190144 bytes
> >> 255 heads, 63 sectors/track, 482 cylinders, total 7744512 sectors
> >> Units = sectors of 1 * 512 = 512 bytes
> >> Sector size (logical/physical): 512 bytes / 512 bytes
> >> I/O size (minimum/optimal): 512 bytes / 512 bytes
> >> Disk identifier: 0x00000000
> >> 
> >>      Device Boot      Start         End      Blocks   Id  System
> >> 
> >> /dev/sdh1   *          63       80324       40131    c  W95 FAT32 (LBA)
> >> /dev/sdh2           80325     7743329     3831502+  83  Linux
> >> 
> >> Anybody got a uSD partition layout that works?  I'm suspecting an issue
> >> with the heads/sectors/cylinders configuration.
> > 
> > Try looking here:
> > http://article.gmane.org/gmane.linux.embedded.yocto.meta-ti/4371
> > 
> > Although I could not confirm this, it seems that the first partition on SD
> > needs to have an even block count (not sure about eMMC though, but I'm
> > guessing the same rules apply).
> 
> I had seen that, and did try even block counts, which didn't help.
> Please try applying the u-boot patch I sent to your build and seeing if
> that fixes the issue for you.  The symptoms you described fit it precisely.

The patch works as advertised. I've applied it on uboot-ti 
053adddee4c97315059e08d4b3f5ebd264ed295f
Great job, thanks.

> 
> It's not obvious whether the problem remains when the upstream changes
> to u-boot that conflict with it are present, but they're past 2014.07 so
> it'd be good to get that patch into meta-ti or the TI u-boot branch.
> I'd push it to OE Core but they're still at 2013.07 which doesn't have
> this problem.  If it also fixes the problems you and Diego are having
> that's more evidence it's worth adding.


-- 

Maciej Borzęcki 
Senior Software Engineer Open-RnD Sp. z o.o. 
www.open-rnd.pl, Facebook, Twitter 
mobile: +48 telefon, fax: +48 42 657 9079 

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem lub 
poufne informacje i została wysłana wyłącznie do wiadomości i użytku osób, do 
których została zaadresowana. Jeśli wiadomość została otrzymana przypadkowo 
zabrania się jej kopiowania lub rozsyłania do osób trzecich. W takim przypadku 
uprasza się o natychmiastowe zniszczenie wiadomości oraz poinformowanie 
nadawcy o zaistniałej sytuacji za pomocą wiadomości zwrotnej. Dziękujemy. 

This message, including any attachments hereto, may contain privileged or 
confidential information and is sent solely for the attention and use of the 
intended addressee(s). If you are not an intended addressee, you may neither 
use this message nor copy or deliver it to anyone. In such case, you should 
immediately destroy this message and kindly notify the sender by reply email. 
Thank you.