Dear "Robert P. J. Day",
In message <alpine.LFD.2.20.1607221529190.7337@localhost.localdomain> you wrote:
>
> never embarrassed to make a fool of myself, i have to admit that,
> while crawling through examples of u-boot boards that define dual
> partitions, i am confused by the following in
> include/configs/taurus.h (only some lines reproduced):
This is your fault. You omit the important parts, i. e. the lines
which end with a "\0" marker which will actually terminate the
definition of one variable and start the next one.
> #define CONFIG_BOOTARGS_AXM \
> "\0" \
> "flash_nfs=run nand_kernel;run nfsargs;run addip;upgrade_available;"\
> "flash_self=run nand_kernel;run setbootargs;upgrade_available;" \
> "flash_self_test=run nand_kernel;run setbootargs addtest; " \
> "upgrade_available;bootm ${kernel_ram};reset\0"
> "net_nfs=run boot_file;tftp ${kernel_ram} ${bootfile};" \
> "run nfsargs;run addip;upgrade_available;bootm " \
> "${kernel_ram};reset\0" \
>
> ... snip ...
>
> "upgrade_available=0\0"
> #endif
>
> what does it mean for "upgrade_available;" to be in the middle of some
> of those command definitions? it's just a variable, what does it
> represent? am i just clueless for never having noticed this sort of
> thing before?
The code really looks like that:
189 "flash_nfs=run nand_kernel;run nfsargs;run
addip;upgrade_available;"\
190 "bootm ${kernel_ram};reset\0" \
191 "flash_self=run nand_kernel;run setbootargs;upgrade_available;" \
192 "bootm ${kernel_ram};reset\0" \
193 "flash_self_test=run nand_kernel;run setbootargs addtest; " \
194 "upgrade_available;bootm ${kernel_ram};reset\0" \
So the code would run the "upgrade_available" _command_ as part of
the command sequences stored in the flash_nfs, flash_self resp.
flash_self_test environment variables.
Note that it has to be a (builtin) command, as a variable reference
would require a "$upgrade_available".
The "upgrade_available" is a board-specific command, implemented in
board/siemens/taurus/taurus.c, function do_upgrade_available().
You may also want to read the README:
911 - Bootcount:
...
917 CONFIG_BOOTCOUNT_ENV
918 If no softreset save registers are found on the hardware
919 "bootcount" is stored in the environment. To prevent a
920 saveenv on all reboots, the environment variable
921 "upgrade_available" is used. If "upgrade_available" is
922 0, "bootcount" is always 0, if "upgrade_available" is
923 1 "bootcount" is incremented in the environment.
924 So the Userspace Applikation must set the
"upgrade_available"
925 and "bootcount" variable to 0, if a boot was successfully.
This is a special measure for boards where there was no good place to
store the boot counter variable in some hardware register, so it was
instead placed in the environment.
Adding Heiko on Cc: so he might add to this explanation if I have
missed something, or interpreted the code incorrectly.
Best regards,
Wolfgang Denk
--
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: w...@denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
- Terry Pratchett, _Eric_
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
