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" <[email protected]> To: Hannes Petermaier <[email protected]>, Cc: [email protected], Naitik Amin <[email protected]> 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/[email protected]/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
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
