[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

Wolfgang Denk skrev:
> Dear Ulf,
> 
> 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.

And as I pointed out, this generates a problem.
The problem is less when the kernel is overwritten than
when the root fs is written.

> 
>>   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?

This assumes people find and read the FAQ, before they call me.
They don't...

>>   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.

The difference is how much knowledge you require from the user.
The average newbie does not know that you have added a CRC to the image
and is less aware that you can check the CRC using suggested commands.

This difference can be measured in the number of incoming telephones calls.

> 
>>> 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?

No, this is part of "drivers/dataflash.c" in the current trunk
This was added to u-boot 11 Jun 2003 according to CHANGELOG
The mtdparts command was added after 11 Jan 2005 according the CHANGELOG

The named partitions is a small extension of "drivers/dataflash.c"


> 
>> 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.


As you see above, I am extending existing code, which is not mtdparts
and since this extends the dataflash support you will reject it, so it is pointless
to even try to submit a patch for inclusion in main trunk.

The reason I sent the patch was to allow people to extend their own u-boot version.
I will make sure the patch is available in my own version as well.

The dataflash partitioning scheme is static, which is a disadvantage, but
If I fix anything, I probably make the partition sizes a configurable item
in my buildroot and generate the warning there, if the kernel size is non compliant.

Anyway mtdparts seems to depend on JFFS2.
That dependency needs to go away first.
If you want to store EXT2 fs in the rootfs partition, you should not have to add JFFS2 code.


> Best regards,
> 
> Wolfgang Denk
> 


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070530/76da2948/attachment.vcf