[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT
wd at denx.de
Wed May 30 01:39:41 CEST 2007
in message <465CB41F.3050002 at atmel.com> you wrote:
> * It is not a special command, it is a configurable side effect of
> reading/writing to dataflash.
It is a special command, as "normal" copy operations don't do this.
> * running mkimage on the host will of course generate the crc check
> but U-boot does not know that they thing you are copying to
> storage is an image so it will not check crc automatically.
It will check it automatically whenever you use such an image, for
example as part of a "bootm" or an "iminfo" command.
> For your recommendation to work, people have to suspect that
> the things stored in flash is bad.
If you get an error message that says "bad CRC" you should indeed
suspect that your image might have been corrupted.
> In my experience, people do not realize that the image is bad, and
> think they have made a mistake when generating the kernel or the root fs
> and spend significant time trying to figure out what the problem
> is and then call me.
Write a FAQ?
> If I generate/check the crc on all writes/reads, then this support
> problem will more or less go away.
> With your proposal, the support problem will remain.
I cannot follow this argument. For me there is no difference between
both CRC tests, except thatone is completely nonstandard and causes a
mess of code in areas where it does not belong.
> > This is not an issue of a special write command, but of such a
> > concept of partitions in flash memory which, at the moment, does not
> > exist.
> The current dataflash drivers divides the flash into partitions.
> In my private version, the partitions can have a name, and the address
> of the partition is automatically stored in an environment variable
> with this name,
I guess that you probably invented your own implementation, or did you
extend the "mtdparts" command for this purpose?
> It would be fairly easy to implement a command which flashes the kernel/rootfs,
> to check that they fit into the named partition.
In the former case, please rewrite your code to fit into the existing
mtdparts framework. In the second case, please post your patches.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with a
different reality system.
More information about the U-Boot