From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT
Date: Tue, 22 May 2007 17:26:42 -0400 [thread overview]
Message-ID: <46536012.1060709@smiths-aerospace.com> (raw)
In-Reply-To: <20070522210405.03530353428@atlas.denx.de>
Wolfgang Denk wrote:
> In message <46535865.6060400@smiths-aerospace.com> you wrote:
>> Looks to me like it would be better defined:
>> #define CFG_ENV_SIZE 0x2000
>> #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
>
> No, this is broken as CFG_ENV_SIZE may be (and often actually is)
> smaller than CFG_ENV_SECT_SIZE
In the case of RAMBOOT where the env is stored in RAM, the flash sector
size is immaterial. "But such discussion is void, as ramboot itself it
not supported officially."
>> The saving grace here is probably:
>> * For a RAMBOOT image, there isn't any incentive to save lots of stuff
>> in the env since it (generally) disappears on a reboot and definitely
>> disappears on a power cycle.
>
> One could argue that a correctly configured ramboot version would
> access the original copy of the environment in flash. But such
> discussion is void, as ramboot itself it not supported officially.
Yup, but arguing minutia keeps geeks entertained. ;-)
>> * On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and
>> vectors which aren't used by a RAMBOOT image so overwriting them is a
>> non-fatal error.
>
> Wrong. You may have timer and other interrupts, so overwriting the
> exception vectors is a Bad Thing (TM).
Beg to differ (granted, I was pretty loose in my description above). If
the env is being stored _before_ u-boot.bin, it means u-boot.bin is not
being stored at location 0x00000000 thus _those_ vectors cannot be the
ones actively being used by the processor. They are the _source_ of the
active vectors (copied to location 0 on relocation) but that is before
they are *hypothetically* corrupted by the user creating 4K++ of env and
then saving the env.
Obviously, the RAMBOOT u-boot.bin image cannot have more than 4K (+/-)
of env variables built in or Very Bad Things would have happened during
the link and/or execution. "But such discussion is void, as ramboot
itself it not supported officially."
> Best regards,
>
> Wolfgang Denk
Best regards,
gvb
next prev parent reply other threads:[~2007-05-22 21:26 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 19:58 [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT Timur Tabi
2007-05-22 20:36 ` Timur Tabi
2007-05-22 20:53 ` Jerry Van Baren
2007-05-22 21:04 ` Wolfgang Denk
2007-05-22 21:07 ` Timur Tabi
2007-05-23 0:15 ` Wolfgang Denk
2007-05-23 15:58 ` Timur Tabi
2007-05-22 21:26 ` Jerry Van Baren [this message]
2007-05-22 21:20 ` Andy Fleming
2007-05-22 21:22 ` Timur Tabi
2007-05-23 0:17 ` Wolfgang Denk
2007-05-23 14:56 ` Timur Tabi
2007-05-22 21:00 ` Wolfgang Denk
2007-05-22 21:30 ` Andy Fleming
2007-05-23 10:04 ` Ladislav Michl
2007-05-23 10:48 ` Ulf Samuelsson
2007-05-23 11:39 ` Ladislav Michl
2007-05-23 12:52 ` Ulf Samuelsson
2007-05-23 13:57 ` Wolfgang Denk
2007-05-23 16:19 ` Ulf Samuelsson
2007-05-24 12:10 ` Ladislav Michl
2007-05-24 13:03 ` Wolfgang Denk
2007-05-24 13:34 ` Ladislav Michl
2007-05-24 19:08 ` Ulf Samuelsson
2007-05-24 21:11 ` Wolfgang Denk
2007-05-24 21:43 ` Ulf Samuelsson
2007-05-24 23:46 ` Wolfgang Denk
2007-05-25 5:37 ` Stefan Roese
2007-05-25 8:50 ` Ladislav Michl
2007-05-23 12:59 ` Ulf Samuelsson
2007-05-23 13:25 ` Ladislav Michl
2007-05-23 16:05 ` Ulf Samuelsson
2007-05-24 12:29 ` Ladislav Michl
2007-05-24 18:34 ` Ulf Samuelsson
2007-05-24 18:35 ` Ulf Samuelsson
2007-05-23 12:59 ` Wolfgang Denk
2007-05-23 15:44 ` Ulf Samuelsson
2007-05-23 18:08 ` Wolfgang Denk
2007-05-24 9:14 ` Ladislav Michl
2007-05-25 9:06 ` Ladislav Michl
-- strict thread matches above, loose matches on Subject: below --
2007-05-26 10:53 Ulf Samuelsson
2007-05-26 13:15 ` Wolfgang Denk
2007-05-28 11:37 ` Ladislav Michl
2007-05-28 14:08 ` Ulf Samuelsson
2007-05-28 15:39 ` Ladislav Michl
2007-05-28 16:16 ` Håvard Skinnemoen
2007-05-28 16:56 ` Ulf Samuelsson
2007-05-28 19:39 ` Ladislav Michl
2007-05-29 0:10 ` Wolfgang Denk
2007-05-29 22:13 ` Ulf Samuelsson
2007-05-29 22:46 ` Wolfgang Denk
2007-05-29 23:15 ` Ulf Samuelsson
2007-05-29 23:39 ` Wolfgang Denk
2007-05-30 0:46 ` Ulf Samuelsson
2007-05-30 6:57 ` Wolfgang Denk
2007-05-30 10:52 ` Ladislav Michl
2007-05-30 13:43 ` Wolfgang Denk
2007-05-30 18:11 ` Ulf Samuelsson
2007-05-30 11:34 Ulf Samuelsson
2007-05-30 12:16 ` Ladislav Michl
2007-05-30 13:47 ` Wolfgang Denk
2007-05-30 18:23 ` Ulf Samuelsson
2007-05-30 23:19 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46536012.1060709@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox