public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Bartlomiej Sieka <tur@semihalf.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server
Date: Thu, 25 Sep 2008 11:49:55 +0200	[thread overview]
Message-ID: <48DB5EC3.8000604@semihalf.com> (raw)
In-Reply-To: <20080925085545.AEDAF248EE@gemini.denx.de>

Wolfgang Denk wrote:
> Dear Bartek,
> 
> in message <48DB48F5.3010204@semihalf.com> you wrote:
>>> I think "auto-update" is not a good name (especially since it has a
>>> different meaning than the similar sounding "autoload"0; also there is
>>> a typo in "sofware".
>>>
>>> But most of all - do we really need a new environment variable? What's
>>> wrong with our good old "bootfile" ?
>> The only concern here is the interaction with bootp and dhcp commands --
>> they will set the "bootfile" env. variable to the file name
>> got from the server, and the next time around U-Boot will try to use
>> that file name to get the update. So I'd rather stick with a separate 
>> env. variable for the name of the update file.
> 
> I see. Maybe we should call the variable "updatefile" or similar,
> then?

How about "au_file"? "updatefile" suffers from similarity to the
commonly used (although not documented) "update" env. variable. But I'm
fine either way, just let me know what you prefer.

[...]
>>>> @@ -290,6 +293,10 @@ void main_loop (void)
>>>>  	char bcs_set[16];
>>>>  #endif /* CONFIG_BOOTCOUNT_LIMIT */
>>>>  
>>>> +#if defined(CONFIG_AU_TFTP)
>>>> +	au_tftp ();
>>>> +#endif /* CONFIG_AU_TFTP */
>>>> +
>>>>  #if defined(CONFIG_VFD) && defined(VFD_TEST_LOGO)
>>>>  	ulong bmp = 0;		/* default bitmap */
>>>>  	extern int trab_vfd (ulong bitmap);
>>> You definitely don't want to add  the  function  call  right  in  the
>>> middle of variable declarations, or do you?
>> The idea is to have au_tftp() called as early as possible, before any
>> other functions in main_loop().
> 
> Yes, but this is C, not C++, so declarations go only at the  bginning
> of  the  function, then follows code (and no more declarations unless
> you open a new block).
> 
>> So if we move the call to au_tftp() someplace below, then when
>> both CONFIG_VFD and VFD_TEST_LOGO are defined, we'll have a call to
>> trab_vfd(), which will happen before the software update.
> 
> So you will either have to add some  more  #ifdef's,  or  think  what
> could  happen  if the VFD (Vacuum Fluorescent Display) initialization
> code runs first - I would not expect any negative impact?

I don't think there will be any negative impact per se, the update
procedure will just start a bit later (the time needed to display the
bitmap on the FVD).

Will move au_tftp() call till after the VFD stuff.

Regards,
Bartlomiej Sieka

  reply	other threads:[~2008-09-25  9:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 15:03 [U-Boot] Automatic software updates in U-Boot Bartlomiej Sieka
2008-09-18 15:03 ` [U-Boot] [PATCH 1/3] net: Make TFTP server timeout configurable Bartlomiej Sieka
2008-09-18 15:17   ` Jerry Van Baren
2008-09-18 21:54     ` Graeme Russ
2008-09-19  1:37       ` Jerry Van Baren
2008-09-19  5:52     ` Bartlomiej Sieka
2008-09-22 20:42       ` Wolfgang Denk
2008-09-25  6:17         ` Bartlomiej Sieka
2008-09-18 15:03 ` [U-Boot] [PATCH 2/3] Automatic software update from TFTP server Bartlomiej Sieka
2008-09-22 21:03   ` Wolfgang Denk
2008-09-25  8:16     ` Bartlomiej Sieka
2008-09-25  8:55       ` Wolfgang Denk
2008-09-25  9:49         ` Bartlomiej Sieka [this message]
2008-09-25 10:01           ` Wolfgang Denk
2008-09-26  8:46             ` Detlev Zundel
2008-09-25 15:33       ` Andrew Dyer
2008-09-25 16:28         ` Kim Phillips
2008-09-25 16:24           ` Jerry Van Baren
2008-09-25 18:17           ` Wolfgang Denk
2008-09-25 19:21             ` Kim Phillips
2008-09-26  8:08               ` Bartlomiej Sieka
2008-09-26  8:29                 ` Wolfgang Denk
2008-09-26  8:29                   ` Bartlomiej Sieka
2008-09-18 15:03 ` [U-Boot] [PATCH 3/3] FIT: output image load address for type 'firmware', fix debug msg while there Bartlomiej Sieka
2008-10-01 13:26 ` [U-Boot] Automatic software updates in U-Boot -- version 2 Bartlomiej Sieka
2008-10-13 22:57   ` Wolfgang Denk
2008-10-14 12:42     ` Bartlomiej Sieka
2008-10-14 13:47       ` Wolfgang Denk
2008-10-14 20:07       ` Wolfgang Denk
2008-10-15  9:45         ` Bartlomiej Sieka
2008-10-01 13:26 ` [U-Boot] [PATCH v2 1/6] flash: factor out adjusting of Flash address to the end of sector Bartlomiej Sieka
2008-10-08  7:39   ` Bartlomiej Sieka
2008-10-08  7:47     ` Stefan Roese
2008-10-08  8:05       ` Bartlomiej Sieka
2008-10-08  8:16         ` Wolfgang Denk
2008-10-08 12:02           ` Stefan Roese
2008-10-13 22:28             ` Wolfgang Denk
2008-10-08 17:38           ` Ben Warren
2008-10-13 22:30             ` Wolfgang Denk
2008-10-01 13:26 ` [U-Boot] [PATCH v2 2/6] net: express the first argument to NetSetTimeout() in milliseconds Bartlomiej Sieka
2008-10-06  5:13   ` Ben Warren
2008-10-01 13:26 ` [U-Boot] [PATCH v2 3/6] net: Make TFTP server timeout configurable Bartlomiej Sieka
2008-10-06  5:13   ` Ben Warren
2008-10-01 13:26 ` [U-Boot] [PATCH v2 4/6] Restore alphabetic ordering in common/Makefile Bartlomiej Sieka
2008-10-08 12:29   ` Jean-Christophe PLAGNIOL-VILLARD
2008-10-08 12:58     ` Bartlomiej Sieka
2008-10-08 14:50       ` Jean-Christophe PLAGNIOL-VILLARD
2008-10-09  8:40         ` Bartlomiej Sieka
2008-10-01 13:26 ` [U-Boot] [PATCH v2 5/6] Automatic software update from TFTP server Bartlomiej Sieka
2008-10-13 22:37   ` Wolfgang Denk
2008-10-01 13:26 ` [U-Boot] [PATCH v2 6/6] FIT: output image load address for type 'firmware', fix message while there Bartlomiej Sieka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48DB5EC3.8000604@semihalf.com \
    --to=tur@semihalf.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox