From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 25 Sep 2008 10:55:45 +0200 Subject: [U-Boot] [PATCH 2/3] Automatic software update from TFTP server In-Reply-To: <48DB48F5.3010204@semihalf.com> References: <12217502093845-git-send-email-tur@semihalf.com> <12217502101047-git-send-email-tur@semihalf.com> <20080922210308.A5C1E248EE@gemini.denx.de> <48DB48F5.3010204@semihalf.com> Message-ID: <20080925085545.AEDAF248EE@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 could the code be extended to be usable for NAND flash / > > DataFlash / OneNAND / IDE storage devices as well? > > Primarily, FIT specification for the update file will have to be > extended. Current approach is able to handle a series of > pairs, where the address is enough for U-Boot to tell where the data > should go. If we are to handle other storage types, we need to specify > which storage type the data should go to, and also provide a > type-specific location. This is somewhat akin to the way we access and > boot from these storage types: we use type-specific commands (nand, > nboot, ide, diskboot, etc.). > > Also, it would be of course nice to have a framework within U-Boot for > generic data copying between storage types, that would hide all the > type-specific details and provide uniform interface. Agreed. You want devices and a mount command, I think ;-) Is anybody on the list volunteering to check what could be lifted from the V2 code? > >> @@ -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? > Note that there are several other cases in the main_loop() where > conditionally included code introduces declarations intermixed with > instructions. If this issue is to be cleaned-up, then let's have it done > as a separate patch. Are there? I don't see any below these lines: 293 #if defined(CONFIG_VFD) && defined(VFD_TEST_LOGO) 294 ulong bmp = 0; /* default bitmap */ 295 extern int trab_vfd (ulong bitmap); 296 297 #ifdef CONFIG_MODEM_SUPPORT 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 Ever try. Ever fail. No matter. Try again. Fail again. Fail better. -- S. Beckett