[U-Boot] uboot env in mmc partition

[Naitik Amin]

Below is the layout of my partitions.

[root at IM /root]# cat /proc/partitions
major minor  #blocks  name

 179        0    3887104 mmcblk0
 179        1      20480 mmcblk0p1
 179        2     512000 mmcblk0p2
 179        3       1024 mmcblk0p3
 179        4         64 mmcblk0p4

Further explanation
Partition 1: Partition type: 0xB Fat32 (Holds zImage, dtb, rbf, uboot 
startup script)
Partition 2: Partititon type: 0x83 ext3 (Holds rootfs)
Partition 3: Partition type: A2 (raw) MBR looks for preloader at the 
beginning of the A2 partition. (Holds Preloader, followed by uboot)
Partition 4: Partition type: A3 (raw) To hold the uboot-env (Newly 
created)



From:   "Peter A. Bigot" <pab at pabigot.com>
To:     Hannes Petermaier <Hannes.Petermaier at br-automation.com>, 
Cc:     u-boot at lists.denx.de, Naitik Amin <Naitik.Amin at ametek.com>
Date:   09/03/2014 10:23 AM
Subject:        Re: [U-Boot] uboot env in mmc partition



On 09/03/2014 09:14 AM, Hannes Petermaier wrote:
>> On 09/03/2014 07:54 AM, Naitik Amin wrote:
>>> Hi Hannes,
>>>
>>> So I did as you had indicated and made some progress, so now, my
> #defines
>>> look as below.
>>> #define CONFIG_SYS_MMC_ENV_DEV          0       /* device 0 */
>>> #define CONFIG_ENV_OFFSET               0x21900000
>>>
>>> I calculated the env offset from the block number it was on based on
> the
>>> first block number of the partition.
>>>
>>> Doing this on uboot startup, I dont get the warning saying, using
> default
>>> environment. Neither it complained abt crc error. So it liked it
> seems.
>>> But what it did is it trashed the partition which had my dtb and
> zImage.
>>> Its a completely different partition. So after that, the bootup gets
>>> halted. Any ideas ? What may have trashed the partition ?
>> Look at: 
http://www.mail-archive.com/u-boot@lists.denx.de/msg146396.html
>>
>> and see if that's relevant, specifically the second patch which 
restores
>> the mmc device offset calculations to the values that correspond to the
>> partition number that's represented in the device structure.
>>
>> Peter
> Hi Peter,
> i don't think that your patch has influence on this issue, due to no
> partition switching is done anymore.

That may be the case: I missed most of the previous discussion of this 
issue.  All I know is that if mmc->part_num is 0 when the MMC 
environment code is entered, then when it leaves the capacity and lba 
fields of the device are no longer correct.  So it'd seemed plausible 
that if mmc_switch_part were invoked somewhere when looking for an 
environment partition it could explain an anomaly with subsequent use of 
the device.

> Further i would like to check your patch series, i am not sure if there 
is
> everything ok.
> I will do so tommorow - i am right in thinking that you are using MMC 
not
> eMMC ?

There is eMMC on the BeagleBone I'm using, but it's been zeroed and is 
not used.  The problem arises in SPL mode on a uSD card with two 
partitions neither of which is an environment.  For full context see the 
meta-ti email thread referenced in the cover letter.

Peter