[U-Boot] [PATCH 2/3] env_mmc: allow negative CONFIG_ENV_OFFSET

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/22/2013 12:00 PM, Stephen Warren wrote:
> On 05/22/2013 09:46 AM, Tom Rini wrote:
>> On Tue, May 21, 2013 at 02:25:20PM -0600, Stephen Warren wrote:
>> 
>>> From: Stephen Warren <swarren at nvidia.com>
>>> 
>>> A negative value of CONFIG_ENV_OFFSET is treated as a
>>> backwards offset from the end of the eMMC device/partition,
>>> rather than a forwards offset from the start.
>>> 
>>> This is useful when a single board may be stuffed with
>>> different eMMC devices, each of which has a different capacity,
>>> and you always want the environment to be stored at the very
>>> end of the device (or eMMC boot partition for example).
>>> 
>>> One example of this case is NVIDIA's Ventana reference board.
>>> 
>>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> 
>> NAK because you aren't also covering CONFIG_ENV_OFFSET_REDUND
>> and you need to update the README as it says ENV_OFFFSET is from
>> the beginning not end.
> 
> env_mmc.c doesn't implement ENV_OFFSET_REDUND, and ENV_IS_IN_MMC
> isn't documented in the README (other config options like
> ENV_OFFSET are all documented relative to the ENV_IS_IN_xxx that
> defines their semantics in the README right now).
> 
> Are you saying you want me to fix those issues before this series
> will be accepted? I have no way to test ENV_OFFSET_REDUND, so I
> really wouldn't want to implement that for MMC, although I guess
> that I could add the ENV_IS_IN_MMC section to the README if you
> need.

CONFIG_ENV_OFFSET_REDUND is already there, but possibly not in the
tegra tree yet?  And yes, if you can write up the ENV_IS_IN_MMC
section that slipped by before, I'd appreciate it.  And you have no
where to grab another 8KiB from? :(

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRnO4hAAoJENk4IS6UOR1WV5oQAKpimzwQ6a9iwPbso+B/BuTi
2sSDODOVJsula8P0rkmA6u7BleJfWoM3AH3VCpBv4hGYCxMimQ6zsKjsGT6UmBER
aHz0t1fLs492VfE2pLxR781rWU6A2M7U9nlsX3HFtVpBYkz6FPgXSP13zT2DW5pN
Bs7oRljUKoiUvL/ISWOLH/TEcMxTf08cmdcsE6vPnqbYUffwedNFc1jDQIEd7POs
cmCPtxi8tLtO1aZrLoqvD9bMKvx8Z8DvahJ5y53xJdhkVufQcTjfK6N1n+DIZrHN
VFt+vhPaKejELdAt6zp0nOpg21yNlyW3x2SfloPoJdJN+29rzI8jbi3wKE38E7rK
DkrUeifSYIttm5gy/icKNIFDCClz50mpa9RlLs7CUbkCJFByHg6vnyGIMwk6Ni3x
Yg6utF1+89V2A8vp2Hov8BuB7Jx7JnLqyffd8KEhXe6Dn8h0gT1z319bhm9YScQQ
P2p674ZU7O7SSwAZDNAAEI5MrQV+Wxlc9I5rvr0UC5hxGnoVpqf4JEDJOQ6zZYLO
sNQCikoFArlYfEJtPdkvWbHmueDCqOhs7KO16mnANjhV9+9dJMNPCEvY/A+3OOD6
eIPaCBpWO4n2Xsw7Qm5zQcFcoBCspTiDPQDAHoDq9mAuYrtuxwdei5Mt1HMeHu7Q
M6QYrPPnRX9taNlH6LN+
=a/cD
-----END PGP SIGNATURE-----