On 24/09/2020 13.35, Mike Looijmans wrote:
>>> Automatically writing the environment on every boot is always a
>>> really bad idea. Never ever do that.
>>
>> Well, there's really no other place on this piece of hardware to
>> implement a boot counter/slot selection. Sure, we could use another part
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 2
On 24/09/2020 12.54, Wolfgang Denk wrote:
> Dear Rasmus,
>
> In message <125344f4-2b69-1c7a-0f5a-6d27ab312...@prevas.dk> you wrote:
>>>
>>> On our newer boards with the 4K erase size, saving the environment now
>>> takes 0.080 seconds instead of 0.53 seconds, which directly translates
>>> to that
Dear Rasmus,
In message <125344f4-2b69-1c7a-0f5a-6d27ab312...@prevas.dk> you wrote:
> >
> > On our newer boards with the 4K erase size, saving the environment now
> > takes 0.080 seconds instead of 0.53 seconds, which directly translates
> > to that much faster boot time since our logic always ca
On 06/05/2020 10.47, Rasmus Villemoes wrote:
> This is roughly the U-Boot side equivalent to commit
> e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The
> motivation is the case where one has a board with several revisions,
> where the SPI flashes have different erase sizes.>
> In
On Wed, 2020-05-06 at 13:06 +0200, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 12:47 +0200, Rasmus Villemoes wrote:
> > On 06/05/2020 12.18, Joakim Tjernlund wrote:
> > > On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> > > > On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote
On Wed, 2020-05-06 at 12:47 +0200, Rasmus Villemoes wrote:
> On 06/05/2020 12.18, Joakim Tjernlund wrote:
> > On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> > > On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > > > CAUTION: This email originated from outside of the organi
On 06/05/2020 12.18, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
>> On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachments unless you recogni
On Wed, 2020-05-06 at 12:15 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 06/05/2020 12.00, Joakim Tjernlund wrote:
> > On Wed, 2
On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
On 06/05/2020 12.00, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
>>
>> On 06/05/2020 11.21, Joakim Tjernlund wrote:
>>
>>> I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff
>>> should be simple to backport
>>> How would fw_env.config be
On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 06/05/2020 11.21, Joakim Tjernlund wrote:
>
> > I can
On 06/05/2020 11.21, Joakim Tjernlund wrote:
> I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff should
> be simple to backport
> How would fw_env.config be dealt with? Just ignored when auto size?
AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
tools, so
On Wed, 2020-05-06 at 11:11 +0200, Rasmus Villemoes wrote:
>
> On 06/05/2020 10.59, Joakim Tjernlund wrote:
> > On Wed, 2020-05-06 at 10:47 +0200, Rasmus Villemoes wrote:
> > > At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean
> > > "use the erase size the chip reports", but th
On 06/05/2020 10.59, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 10:47 +0200, Rasmus Villemoes wrote:
>> At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean
>> "use the erase size the chip reports", but that config
>> option is used in a number of preprocessor conditionals, a
On Wed, 2020-05-06 at 10:47 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> This is roughly the U-Boot side equivalent to commit
> e28
This is roughly the U-Boot side equivalent to commit
e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The
motivation is the case where one has a board with several revisions,
where the SPI flashes have different erase sizes.
In our case, we have an 8K environment, and the flashes h
17 matches
Mail list logo
