[U-Boot] U-Boot Scripting suggestions to decrement, counter in EEPROM.

[U-Boot] U-Boot Scripting suggestions to decrement, counter in EEPROM.

[Tom Evans]

Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> On 17:40 Tue 03 Mar     , Tom Evans wrote:
>> I'm implementing a rather complex boot that involves flags
 >> and counters in EEPROM.
> 
> in which case do you need this?
> 
> update?

Yes, it is when updating the Linux Kernel and Sysroot images.

These are both duplicated. The "alternate" set is updated, then an 
"alternate boot" (a boot from the designated alternate set) is commanded 
with a count limit. If this expires the boot reverts to the original 
boot, otherwise the OS scripts switch "Alternate" and "Active" then 
update the other one. It is more complex involving two sets of counters 
and multiple run-levels etc.

> in u-boot you have better system that involve watchdog and bootcount

It is only currently supported on the PPC8260, requires spare words in a 
CPM SCC (or equivalent by writing bootcount_load() and bootcount_store() 
functions) and is too simplistic for what I need to do. It might work if 
the OS (after boot) could update the U-Boot Environment, but that's way 
too much linking (between Linux and U-Boot) and I don't have a writeable 
environment either.

I was hoping for a suggestion for reading memory locations into shell 
variables. It looks like I'll have to add one of these.

Thank you Jean-Christophe.

-- 
===
Tom Evans      Tom.Evans at ceos.com.au
CEOS Pty Ltd   www.ceos.com.au
3/17 Burgundy St, Heidelberg,
Victoria 3084, Australia

[U-Boot] U-Boot Scripting suggestions to decrement, counter in EEPROM.

[Wolfgang Denk]

Dear Tom Evans,

In message <49ADB5E7.8060604@ceos.com.au> you wrote:
>
> > in u-boot you have better system that involve watchdog and bootcount
> 
> It is only currently supported on the PPC8260, requires spare words in a 

This is not correct. It is at least supported on 8xx, 8260 and 5200,
and easy to add to other processors.

> CPM SCC (or equivalent by writing bootcount_load() and bootcount_store() 
> functions) and is too simplistic for what I need to do. It might work if 
> the OS (after boot) could update the U-Boot Environment, but that's way 
> too much linking (between Linux and U-Boot) and I don't have a writeable 
> environment either.

And you think a writable EEPROM is a reliable way to store data? I say
only this: Good luck!


Best regards,

Wolfgang Denk

-- 
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
We are Microsoft. Unix is irrelevant. Openness is futile.  Prepare to
be assimilated.

[U-Boot] Alignment bug in itest on ARM & doesn't work on big-endian either?

[Tom Evans]

Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> On 17:40 Tue 03 Mar     , Tom Evans wrote:
>> BUG IN ITEST
>> ------------
>> itest crashes ARM chips. I can "iread.b *82000000 == 0",
 >> but "iread.b *82000001 == 0" throws an alignment
 >> exception that kills the box. The code in itest.c is:
>>
>> static long evalexp(char *s, int w)
>> {
>>      long l, *p;
>>
>>      /* if the parameter starts with a * then assume
 >>         is a pointer to the value we want */
>>      if (s[0] == '*') {
>>          p = (long *)simple_strtoul(&s[1], NULL, 16);
>>          l = *p;

> here you are support to use the good accessor
 > readb/readw/readl

Thank you for your response.

readl() is defined in asm-arm/io.h as "__arch_getl(a)" which
is defined as "(*(volatile unsigned int *)(a))" which
doesn't handle misalignment and will still crash.

I think those functions are only meant for I/O reads.

The code then "selects the byte" with the following:

 >>      return (l & ((1 << (w * 8)) - 1));

That selects the LOWER 8/16/32 bits of the 32-bit read.

Which works on a 486, ARM variants with unaligned transfers, but NOT on 
a PPC or any other big-endian CPUs (about half of them supported by U-Boot).

On a big-endian unaligned supporting CPU I'd expect a byte read of 
address "0" to read "3" and a read of "1" to read "4" (in the next 
word!). Ditto for itest.w.

Whoever owns/maintains this code, and/or can test it on a big-endian 
target should fix these, taking hints from the cmd_mem.c code which does 
all of this in a portable manner. I don't have a big-endian target so I 
can't test the big-endian fix.

> the arm does not allow you to do an non aligned access

I know that. The current itest code doesn't. The "indirect pointer 
feature" mustn't be used much if I'm the first one to find these problems.

-- 
===
Tom Evans      Tom.Evans at ceos.com.au
CEOS Pty Ltd   www.ceos.com.au
3/17 Burgundy St, Heidelberg,
Victoria 3084, Australia