* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
@ 2018-02-22 11:30 Stefano Babic
2018-02-22 11:52 ` Lukasz Majewski
0 siblings, 1 reply; 6+ messages in thread
From: Stefano Babic @ 2018-02-22 11:30 UTC (permalink / raw)
To: u-boot
If the bootcounter address is in a cached memory,
a flush of dcache must occur after updateing the bootcounter.
Issue found on i.MX6 where bootcounter is put into the internal
(cached) IRAM.
Signed-off-by: Stefano Babic <sbabic@denx.de>
---
drivers/bootcount/bootcount.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bootcount/bootcount.c b/drivers/bootcount/bootcount.c
index d5ce450..48594a6 100644
--- a/drivers/bootcount/bootcount.c
+++ b/drivers/bootcount/bootcount.c
@@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
raw_bootcount_store(reg, a);
raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
#endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
+ flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
+ CONFIG_SYS_BOOTCOUNT_ADDR +
+ CONFIG_SYS_CACHELINE_SIZE);
}
__weak ulong bootcount_load(void)
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
2018-02-22 11:30 [U-Boot] [PATCH] bootcount: flush after storing the bootcounter Stefano Babic
@ 2018-02-22 11:52 ` Lukasz Majewski
2018-02-22 12:16 ` Stefano Babic
0 siblings, 1 reply; 6+ messages in thread
From: Lukasz Majewski @ 2018-02-22 11:52 UTC (permalink / raw)
To: u-boot
Hi Stefano,
> If the bootcounter address is in a cached memory,
> a flush of dcache must occur after updateing the bootcounter.
>
> Issue found on i.MX6 where bootcounter is put into the internal
> (cached) IRAM.
>
> Signed-off-by: Stefano Babic <sbabic@denx.de>
> ---
> drivers/bootcount/bootcount.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/bootcount/bootcount.c
> b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
> --- a/drivers/bootcount/bootcount.c
> +++ b/drivers/bootcount/bootcount.c
> @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
> raw_bootcount_store(reg, a);
> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
> + flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
> + CONFIG_SYS_BOOTCOUNT_ADDR +
> + CONFIG_SYS_CACHELINE_SIZE);
Is it safe to flush the whole cache line?
For iMX6Q I do use SNVS_LPGR register (0x020CC068). It will preserve
its content after reset caused by WDT (also reset command in u-boot).
I also do use the SINGLEWORD to store "magic" and boot count in a
single 32 bit number.
You may also want to consider using SRC_GPRx registers:
https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
As it shall be safe to use them for bootcount scenario. However, I do
prefer SNVS_LPGR.
> }
>
> __weak ulong bootcount_load(void)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180222/e64bcd38/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
2018-02-22 11:52 ` Lukasz Majewski
@ 2018-02-22 12:16 ` Stefano Babic
2018-02-22 13:03 ` Lukasz Majewski
0 siblings, 1 reply; 6+ messages in thread
From: Stefano Babic @ 2018-02-22 12:16 UTC (permalink / raw)
To: u-boot
Hi Lukasz,
On 22/02/2018 12:52, Lukasz Majewski wrote:
> Hi Stefano,
>
>> If the bootcounter address is in a cached memory,
>> a flush of dcache must occur after updateing the bootcounter.
>>
>> Issue found on i.MX6 where bootcounter is put into the internal
>> (cached) IRAM.
>>
>> Signed-off-by: Stefano Babic <sbabic@denx.de>
>> ---
>> drivers/bootcount/bootcount.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/bootcount/bootcount.c
>> b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
>> --- a/drivers/bootcount/bootcount.c
>> +++ b/drivers/bootcount/bootcount.c
>> @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
>> raw_bootcount_store(reg, a);
>> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
>> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
>> + flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
>> + CONFIG_SYS_BOOTCOUNT_ADDR +
>> + CONFIG_SYS_CACHELINE_SIZE);
>
> Is it safe to flush the whole cache line?
Is there is some drawbacks ?
flush_dcache_range() requires that addresses are aligned with
CONFIG_SYS_CACHELINE_SIZE. I cannot flush a single word.
>
> For iMX6Q I do use SNVS_LPGR register (0x020CC068).
It is a long story...
> It will preserve
> its content after reset caused by WDT (also reset command in u-boot).
> I also do use the SINGLEWORD to store "magic" and boot count in a
> single 32 bit number.
>
I used it in the past - Heiko found issues with recent kernel versions
because kernel is using it. That means, after a rebootwe get what the
kernel has written in it, not the bootcounter anymore.
It looks like, too, that SNVS behavior changes between i.MX6 variants.
Even in manual, there are discordances (on i.MX6Q seems can be used, on
DL seems to be reserved,...).
Due to recent issues, I searched for a suitable place in IRAM.
Anyway, this has nothing to do with the issue. If the storage with the
bootcounter is cached, it must be flushed.
> You may also want to consider using SRC_GPRx registers:
> https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
See above, waiting for Heiko's comment,too.
>
> As it shall be safe to use them for bootcount scenario.
Rather, it looks like it is not safe. Or it was safe, it is not. Or it
depends on i.MX6 revisions....
> However, I do
> prefer SNVS_LPGR.
You're lucky you do not yet go into trouble :-)
>
>> }
>>
>> __weak ulong bootcount_load(void)
>
>
>
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
2018-02-22 12:16 ` Stefano Babic
@ 2018-02-22 13:03 ` Lukasz Majewski
2018-02-23 6:01 ` Heiko Schocher
0 siblings, 1 reply; 6+ messages in thread
From: Lukasz Majewski @ 2018-02-22 13:03 UTC (permalink / raw)
To: u-boot
Hi Stefano,
> Hi Lukasz,
>
> On 22/02/2018 12:52, Lukasz Majewski wrote:
> > Hi Stefano,
> >
> >> If the bootcounter address is in a cached memory,
> >> a flush of dcache must occur after updateing the bootcounter.
> >>
> >> Issue found on i.MX6 where bootcounter is put into the internal
> >> (cached) IRAM.
> >>
> >> Signed-off-by: Stefano Babic <sbabic@denx.de>
> >> ---
> >> drivers/bootcount/bootcount.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/bootcount/bootcount.c
> >> b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
> >> --- a/drivers/bootcount/bootcount.c
> >> +++ b/drivers/bootcount/bootcount.c
> >> @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
> >> raw_bootcount_store(reg, a);
> >> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
> >> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
> >> + flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
> >> + CONFIG_SYS_BOOTCOUNT_ADDR +
> >> + CONFIG_SYS_CACHELINE_SIZE);
> >
> > Is it safe to flush the whole cache line?
>
> Is there is some drawbacks ?
I think not - as we are now in u-boot.
(I do have patches, which add also support for bootcount in SPL - I
will send them when Kconfig prerequisities go into mainline).
>
> flush_dcache_range() requires that addresses are aligned with
> CONFIG_SYS_CACHELINE_SIZE. I cannot flush a single word.
Yes. Correct.
>
> >
> > For iMX6Q I do use SNVS_LPGR register (0x020CC068).
>
> It is a long story...
:-)
>
> > It will preserve
> > its content after reset caused by WDT (also reset command in
> > u-boot). I also do use the SINGLEWORD to store "magic" and boot
> > count in a single 32 bit number.
> >
>
> I used it in the past - Heiko found issues with recent kernel versions
> because kernel is using it. That means, after a rebootwe get what the
> kernel has written in it, not the bootcounter anymore.
You mean the SRC_GPRx registers?
>
> It looks like, too, that SNVS behavior changes between i.MX6 variants.
> Even in manual, there are discordances (on i.MX6Q seems can be used,
> on DL seems to be reserved,...).
What I can say.... :/
>
> Due to recent issues, I searched for a suitable place in IRAM.
Ok.
>
> Anyway, this has nothing to do with the issue. If the storage with the
> bootcounter is cached, it must be flushed.
Yes. Of course.
>
>
> > You may also want to consider using SRC_GPRx registers:
> > https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
>
> See above, waiting for Heiko's comment,too.
Ok. Maybe the reply from the NXP community is not complete...
>
> >
> > As it shall be safe to use them for bootcount scenario.
>
> Rather, it looks like it is not safe. Or it was safe, it is not. Or it
> depends on i.MX6 revisions....
It would be great if Heiko could share the problem with SRC_GPRx
registers. I would like to know the root cause for the future usage.
>
> > However, I do
> > prefer SNVS_LPGR.
>
> You're lucky you do not yet go into trouble :-)
Devlopment by luck :-)
>
> >
> >> }
> >>
> >> __weak ulong bootcount_load(void)
> >
> >
> >
>
> Best regards,
> Stefano
>
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180222/9814b1b6/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
2018-02-22 13:03 ` Lukasz Majewski
@ 2018-02-23 6:01 ` Heiko Schocher
2018-02-23 9:05 ` Lukasz Majewski
0 siblings, 1 reply; 6+ messages in thread
From: Heiko Schocher @ 2018-02-23 6:01 UTC (permalink / raw)
To: u-boot
Hello Lukasz,
Am 22.02.2018 um 14:03 schrieb Lukasz Majewski:
> Hi Stefano,
>
>> Hi Lukasz,
>>
>> On 22/02/2018 12:52, Lukasz Majewski wrote:
>>> Hi Stefano,
>>>
>>>> If the bootcounter address is in a cached memory,
>>>> a flush of dcache must occur after updateing the bootcounter.
>>>>
>>>> Issue found on i.MX6 where bootcounter is put into the internal
>>>> (cached) IRAM.
>>>>
>>>> Signed-off-by: Stefano Babic <sbabic@denx.de>
>>>> ---
>>>> drivers/bootcount/bootcount.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/bootcount/bootcount.c
>>>> b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
>>>> --- a/drivers/bootcount/bootcount.c
>>>> +++ b/drivers/bootcount/bootcount.c
>>>> @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
>>>> raw_bootcount_store(reg, a);
>>>> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
>>>> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
>>>> + flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
>>>> + CONFIG_SYS_BOOTCOUNT_ADDR +
>>>> + CONFIG_SYS_CACHELINE_SIZE);
>>>
>>> Is it safe to flush the whole cache line?
>>
>> Is there is some drawbacks ?
>
> I think not - as we are now in u-boot.
>
> (I do have patches, which add also support for bootcount in SPL - I
> will send them when Kconfig prerequisities go into mainline).
>
>>
>> flush_dcache_range() requires that addresses are aligned with
>> CONFIG_SYS_CACHELINE_SIZE. I cannot flush a single word.
>
> Yes. Correct.
>
>>
>>>
>>> For iMX6Q I do use SNVS_LPGR register (0x020CC068).
>>
>> It is a long story...
>
> :-)
>
>>
>>> It will preserve
>>> its content after reset caused by WDT (also reset command in
>>> u-boot). I also do use the SINGLEWORD to store "magic" and boot
>>> count in a single 32 bit number.
>>>
>>
>> I used it in the past - Heiko found issues with recent kernel versions
>> because kernel is using it. That means, after a rebootwe get what the
>> kernel has written in it, not the bootcounter anymore.
>
> You mean the SRC_GPRx registers?
>
>>
>> It looks like, too, that SNVS behavior changes between i.MX6 variants.
>> Even in manual, there are discordances (on i.MX6Q seems can be used,
>> on DL seems to be reserved,...).
>
> What I can say.... :/
>
>>
>> Due to recent issues, I searched for a suitable place in IRAM.
>
> Ok.
>
>>
>> Anyway, this has nothing to do with the issue. If the storage with the
>> bootcounter is cached, it must be flushed.
>
> Yes. Of course.
>
>>
>>
>>> You may also want to consider using SRC_GPRx registers:
>>> https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
>>
>> See above, waiting for Heiko's comment,too.
>
> Ok. Maybe the reply from the NXP community is not complete...
Hmm.. I have here an imx6dl based board:
CPU: Freescale i.MX6DL rev1.3 at 792 MHz
and I tried to put the bootcounter into the iram, but found no addr, which
is stable over a reboot from linux into U-Boot ... I must admit, that I
use the GPU may it use iram? Nevertheless, unsure place.
Tried SRC_GPRx registers, but also not stable after a "boot linux - reboot to
U-Boot" cycle.
imx6 D/QL UML says
SRC_GPRx with x = 5-8 for quad only -> so not usable for me
and x=(1-8):
"Holds argument of entry function for coreX. The SRC ensures that the register
value will persist across system resets."
with (X=0-3)
So, the core may uses them ...
The S/DL manual says to this registers:
"Read/write general purpose bits used to store an arbitrary value.
This register is used by the ROM code and should not be used by application software."
So also on S/DL no chance to use this registers without risk ...
I have on my hw a pfuze100 and I stored the bootcounter in the 4 8bit
registers MEMA - MEMD ... as we have no battery attached to the pfuze
this works fine... as you said "Development by luck" :-D
Hmm... SVN_LGPR regsiter ... sounds good. Tried it fast here on my hw,
seems to work ... but may instability remains, UML says:
"When GPR_SL or GPR_HL bit is set, the register cannot be programmed."
Once GPR_SL bit is set, it can only cleared through System Reset ...
May a risk?
bye,
Heiko
>
>>
>>>
>>> As it shall be safe to use them for bootcount scenario.
>>
>> Rather, it looks like it is not safe. Or it was safe, it is not. Or it
>> depends on i.MX6 revisions....
>
> It would be great if Heiko could share the problem with SRC_GPRx
> registers. I would like to know the root cause for the future usage.
>
>>
>>> However, I do
>>> prefer SNVS_LPGR.
>>
>> You're lucky you do not yet go into trouble :-)
>
> Devlopment by luck :-)
>
>>
>>>
>>>> }
>>>>
>>>> __weak ulong bootcount_load(void)
>>>
>>>
>>>
>>
>> Best regards,
>> Stefano
>>
>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> 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
>
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] bootcount: flush after storing the bootcounter
2018-02-23 6:01 ` Heiko Schocher
@ 2018-02-23 9:05 ` Lukasz Majewski
0 siblings, 0 replies; 6+ messages in thread
From: Lukasz Majewski @ 2018-02-23 9:05 UTC (permalink / raw)
To: u-boot
Hi Heiko,
> Hello Lukasz,
>
> Am 22.02.2018 um 14:03 schrieb Lukasz Majewski:
> > Hi Stefano,
> >
> >> Hi Lukasz,
> >>
> >> On 22/02/2018 12:52, Lukasz Majewski wrote:
> >>> Hi Stefano,
> >>>
> >>>> If the bootcounter address is in a cached memory,
> >>>> a flush of dcache must occur after updateing the bootcounter.
> >>>>
> >>>> Issue found on i.MX6 where bootcounter is put into the internal
> >>>> (cached) IRAM.
> >>>>
> >>>> Signed-off-by: Stefano Babic <sbabic@denx.de>
> >>>> ---
> >>>> drivers/bootcount/bootcount.c | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/drivers/bootcount/bootcount.c
> >>>> b/drivers/bootcount/bootcount.c index d5ce450..48594a6 100644
> >>>> --- a/drivers/bootcount/bootcount.c
> >>>> +++ b/drivers/bootcount/bootcount.c
> >>>> @@ -59,6 +59,9 @@ __weak void bootcount_store(ulong a)
> >>>> raw_bootcount_store(reg, a);
> >>>> raw_bootcount_store(reg + 4, BOOTCOUNT_MAGIC);
> >>>> #endif /* defined(CONFIG_SYS_BOOTCOUNT_SINGLEWORD */
> >>>> + flush_dcache_range(CONFIG_SYS_BOOTCOUNT_ADDR,
> >>>> + CONFIG_SYS_BOOTCOUNT_ADDR +
> >>>> + CONFIG_SYS_CACHELINE_SIZE);
> >>>
> >>> Is it safe to flush the whole cache line?
> >>
> >> Is there is some drawbacks ?
> >
> > I think not - as we are now in u-boot.
> >
> > (I do have patches, which add also support for bootcount in SPL - I
> > will send them when Kconfig prerequisities go into mainline).
> >
> >>
> >> flush_dcache_range() requires that addresses are aligned with
> >> CONFIG_SYS_CACHELINE_SIZE. I cannot flush a single word.
> >
> > Yes. Correct.
> >
> >>
> >>>
> >>> For iMX6Q I do use SNVS_LPGR register (0x020CC068).
> >>
> >> It is a long story...
> >
> > :-)
> >
> >>
> >>> It will preserve
> >>> its content after reset caused by WDT (also reset command in
> >>> u-boot). I also do use the SINGLEWORD to store "magic" and boot
> >>> count in a single 32 bit number.
> >>>
> >>
> >> I used it in the past - Heiko found issues with recent kernel
> >> versions because kernel is using it. That means, after a rebootwe
> >> get what the kernel has written in it, not the bootcounter
> >> anymore.
> >
> > You mean the SRC_GPRx registers?
> >
> >>
> >> It looks like, too, that SNVS behavior changes between i.MX6
> >> variants. Even in manual, there are discordances (on i.MX6Q seems
> >> can be used, on DL seems to be reserved,...).
> >
> > What I can say.... :/
> >
> >>
> >> Due to recent issues, I searched for a suitable place in IRAM.
> >
> > Ok.
> >
> >>
> >> Anyway, this has nothing to do with the issue. If the storage with
> >> the bootcounter is cached, it must be flushed.
> >
> > Yes. Of course.
> >
> >>
> >>
> >>> You may also want to consider using SRC_GPRx registers:
> >>> https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
> >>
> >> See above, waiting for Heiko's comment,too.
> >
> > Ok. Maybe the reply from the NXP community is not complete...
>
> Hmm.. I have here an imx6dl based board:
>
> CPU: Freescale i.MX6DL rev1.3 at 792 MHz
>
> and I tried to put the bootcounter into the iram, but found no addr,
> which is stable over a reboot from linux into U-Boot ... I must
> admit, that I use the GPU may it use iram? Nevertheless, unsure place.
>
> Tried SRC_GPRx registers, but also not stable after a "boot linux -
> reboot to U-Boot" cycle.
>
> imx6 D/QL UML says
> SRC_GPRx with x = 5-8 for quad only -> so not usable for me
>
> and x=(1-8):
>
> "Holds argument of entry function for coreX. The SRC ensures that the
> register value will persist across system resets."
>
> with (X=0-3)
>
> So, the core may uses them ...
>
> The S/DL manual says to this registers:
> "Read/write general purpose bits used to store an arbitrary value.
> This register is used by the ROM code and should not be used by
> application software."
>
> So also on S/DL no chance to use this registers without risk ...
This was also my concern. Hence I've asked NXP community (support)
explicitly:
https://community.nxp.com/message/985790?commentID=985790&et=watches.email.thread#comment-985790
Maybe the BootROM is different for different SoC versions? (My iMX6Q is
rev. 1.5, yours iMX6DL is 1.3)?
Maybe it would be good to ask your case on the NXP community site as
well?
Similar symptomps I had with some Samsung SoCs. In their case the FBL
(not BootROM) from Samsung was using those registers to check if we go
out from "sleep" mode.
However, what I've understood from iMX6 User Manual, the BootROM on iMX6
needs values from SRC_GPRx - and it shall restore the LInux without the
need for bootloader intervention.
>
> I have on my hw a pfuze100 and I stored the bootcounter in the 4 8bit
> registers MEMA - MEMD ... as we have no battery attached to the pfuze
> this works fine... as you said "Development by luck" :-D
:-)
The same case for me. I also don't have the battery attached - hence
the SNVS_LGPR is OK to use.
>
> Hmm... SVN_LGPR regsiter ... sounds good. Tried it fast here on my hw,
> seems to work ... but may instability remains, UML says:
>
> "When GPR_SL or GPR_HL bit is set, the register cannot be programmed."
But this would be need to be set by other user application.
Also, this register is marked as the one to be used with "user
application".
>
> Once GPR_SL bit is set, it can only cleared through System Reset ...
>
> May a risk?
If your user write an application, which will use this regsiter, then
yes, it may be a risk.
>
> bye,
> Heiko
> >
> >>
> >>>
> >>> As it shall be safe to use them for bootcount scenario.
> >>
> >> Rather, it looks like it is not safe. Or it was safe, it is not.
> >> Or it depends on i.MX6 revisions....
> >
> > It would be great if Heiko could share the problem with SRC_GPRx
> > registers. I would like to know the root cause for the future usage.
> >
> >>
> >>> However, I do
> >>> prefer SNVS_LPGR.
> >>
> >> You're lucky you do not yet go into trouble :-)
> >
> > Devlopment by luck :-)
> >
> >>
> >>>
> >>>> }
> >>>>
> >>>> __weak ulong bootcount_load(void)
> >>>
> >>>
> >>>
> >>
> >> Best regards,
> >> Stefano
> >>
> >>
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH, Managing Director: Wolfgang
> > Denk 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
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180223/0341578c/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-23 9:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-22 11:30 [U-Boot] [PATCH] bootcount: flush after storing the bootcounter Stefano Babic
2018-02-22 11:52 ` Lukasz Majewski
2018-02-22 12:16 ` Stefano Babic
2018-02-22 13:03 ` Lukasz Majewski
2018-02-23 6:01 ` Heiko Schocher
2018-02-23 9:05 ` Lukasz Majewski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.