Below is the layout of my partitions.
[root@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@pabigot.com To: Hannes Petermaier Hannes.Petermaier@br-automation.com, Cc: u-boot@lists.denx.de, Naitik Amin Naitik.Amin@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