Re: [U-Boot] [RFD] store env size in env area (+ cookie + len)
Am 12.08.2010 09:54, schrieb Frans Meulenbroeks:
2010/8/12 Matthias Weißerweisserm@arcor.de:
Why not store the size of the environment sector as env variable? The size should be only needed for storing the environment and not for loading (as it is terminated by a '\0'). So we could load the environment, check for "env_size" and if its not there take the value from fw_env.config
Currently the crc of the environment is calculated and if it does not match with the stored crc the default environment is used. For determining the crc the size is needed so storing the size in the env creates some form of catch-22. Of course the code could be modified to first peek at the unverified env to find the size. That is a different approach. Imho not too neat.
I see. I was thinking that the CRC is only calculated over the environment until the '\0' end mark is reached. But after checking my environment code I see that the CRC is calculated over the whole sector.
Wrt the format: I understood from the mail from Reinhard that the way the env is stored is going to change anyway. I saw the patches of Wolfgang pass by, but didn't have time to study them yet.
I also didn't go that deep into Wolfgangs patches but from what I understand the "on disk format" will not change. Will it?
Maybe the size could be added at the end of the environment (behind the '\0'). So we wouldn't loose compatibility.
Matthias
Dear Matthias Weißer,
Wrt the format: I understood from the mail from Reinhard that the way the env is stored is going to change anyway. I saw the patches of Wolfgang pass by, but didn't have time to study them yet.
What I meant, is, that with those patches and the environment in RAM not being a 1:1 copy of what is stored "on disk" anymore, its easy to write it in any format you desire onto "disk".
I also didn't go that deep into Wolfgangs patches but from what I understand the "on disk format" will not change. Will it?
No its not changed. Only the format in RAM is changed to a hashed list. Therefore it would not matter how it is stored on external media since a "read" and "write" function is needed anyway.
You only need to change/rewrite those functions to store the environment in any fashion you like...
Reinhard
Thinking more about it:
You only need to change/rewrite those functions to store the environment in any fashion you like...
The header could also include the current length of the env, not just the max.
And env in EEPROM would benefit in speed if only the used space is written/read. A 16k ENV area in I2C EEPROM can take a few seconds to save if not tuned to max. speed. If the ENV uses just a few 100 Bytes, which it normally does, it would speed up saving (and reading).
<duck> one could also save the env in XML format... </duck>
Reinhard
Dear Reinhard Meyer,
In message 4C63B262.8070004@emk-elektronik.de you wrote:
And env in EEPROM would benefit in speed if only the used space is written/read. A 16k ENV area in I2C EEPROM can take a few seconds to save if not tuned to max. speed. If the ENV uses just a few 100 Bytes, which it normally does, it would speed up saving (and reading).
This is an improvement that can be implemented independent from other changes discussed here. Patches are welcome.
<duck> one could also save the env in XML format... </duck>
Yes, or as a SQLite data base. There are many options. Not all of them are really clever ones, though.
Best regards,
Wolfgang Denk
Dear Reinhard Meyer,
In message 4C63AE37.1020206@emk-elektronik.de you wrote:
understand the "on disk format" will not change. Will it?
No its not changed. Only the format in RAM is changed to a hashed list. Therefore it would not matter how it is stored on external media since a "read" and "write" function is needed anyway.
You only need to change/rewrite those functions to store the environment in any fashion you like...
Please spell "compatibility".
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
You only need to change/rewrite those functions to store the environment in any fashion you like...
Please spell "compatibility".
Hmm, I think all IBM(R) PC(R) USERS(R) have spelled that alot. Where this lead to, everyone knows... Though its nice that some Win95 Programs still run under Vista ;)
And who says the "different" storage could not be an configuration option?
Reinhard
Dear Reinhard Meyer,
In message 4C63B8E6.8030805@emk-elektronik.de you wrote:
Hmm, I think all IBM(R) PC(R) USERS(R) have spelled that alot. Where this lead to, everyone knows... Though its nice that some Win95 Programs still run under Vista ;)
And who says the "different" storage could not be an configuration option?
I really fail to see any real advantages either. The existing format has the benefit of being simple and efficient for the purposes it has been designed for.
If you want different output formats, you can add more data formats to the "export" and "import" options of the new environment handling code, but you also would have to add bootstrap code to read this format from early environment (i. e. without data or bss segments, and with minimal stack size).
My feeling is that the result would be complicated and inefficient.
Best regards,
Wolfgang Denk
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
In message 4C63ACA6.6080303@arcor.de you wrote:
Am 12.08.2010 09:54, schrieb Frans Meulenbroeks:
2010/8/12 Matthias Weißerweisserm@arcor.de:
Why not store the size of the environment sector as env variable? The size should be only needed for storing the environment and not for loading (as it is terminated by a '\0'). So we could load the environment, check for "env_size" and if its not there take the value from fw_env.config
Currently the crc of the environment is calculated and if it does not match with the stored crc the default environment is used. For determining the crc the size is needed so storing the size in the env creates some form of catch-22. Of course the code could be modified to first peek at the unverified env to find the size. That is a different approach. Imho not too neat.
Was this an off-list reply? I cannot see any trace of this message on the list.
Please always keep the list on Cc: !
I see. I was thinking that the CRC is only calculated over the environment until the '\0' end mark is reached. But after checking my environment code I see that the CRC is calculated over the whole sector.
For the sake of simplicity it should be possible to assume that the CRC is correct, look up the env_size variable, and then check the CRC with the length thus found.
Wrt the format: I understood from the mail from Reinhard that the way the env is stored is going to change anyway. I saw the patches of Wolfgang pass by, but didn't have time to study them yet.
The external storage format will NOT change. Compatibility with existing code (not only in U-Boot) is a major concern of all such changes.
I also didn't go that deep into Wolfgangs patches but from what I understand the "on disk format" will not change. Will it?
No, it ill remain exactly the same.
Maybe the size could be added at the end of the environment (behind the '\0'). So we wouldn't loose compatibility.
It would add new issues, like when the envrionment is filing up.
Best regards,
Wolfgang Denk
participants (3)
-
Matthias Weißer -
Reinhard Meyer -
Wolfgang Denk