How to modify defconfig file - make savedefconfig?
What is the "right" way to modify a defconfig file? Most sources I've found just say things like "edit the defconfig file". That seems error-prone -- especially when dealing with settings that have side effects. I did stumble across one mention of "make savedefconfig", and this seems to be the right way to modify a defconfig file: make myboard_defconfig make menuconfig make savedefconfig cp defconfig configs/myboard_defconfig Do people manually edit their defconfig file when they want to make a change, or do they use "make savedefconfig" like I show above? One reason I'm asking is that the original defconfig file provided by the silicon vendor (Renesas) appears to be a manually stripped-down ..config file, because when I do make vendors_defconfig make savedefconfig The defconfig file generated by 'make savedefconfig' looks _nothing_ like the starting vendors_defconfig. The new defconfig generates the same .config file as the vendors_defconfig file. But the vendors_defconfig file is arranged completely differently with different/extra comments, extra blank lines, etc. -- Grant
Re: Compile only changed files when doing 'make'?
On 2022-01-25, Grant Edwards wrote: > I'm working on a Renesas supplied port of U-Boot, and it seems that > 'make' always compiles every single (configured) source file instead > compiling only the source files that have been changed since the > previous 'make'. This problem appears to be caused by an incompatibility between the Kbuild infrastructure2 and GNU make-4.3. Switching to make-4.2.1 solved the problem. The U-Boot source tree we're using is the v2017.01 branch. It's the latest supported by the Renesas board support files. I'm not very happy they haven't contributed the supported upstream to make it easier to support newer versions. I've asked Renesas about this, and they have no plans to either support a newer version of U-Boot or contribute their support files. :/ I assume that this Kbuild incompatibility with make-4.3 has been fixed in newer versions of U-Boot. If this Kbuild problem is familiar to anybody, and you know where the fix was made, I'd appreciate a pointer so that I can back-port that fix to my v2017.01 sources. Thanks... -- Grant
Compile only changed files when doing 'make'?
I'm working on a Renesas supplied port of U-Boot, and it seems that 'make' always compiles every single (configured) source file instead compiling only the source files that have been changed since the previous 'make'. I've never run into this before on projects that use 'make', and it makes development of U-Boot rather grueling. Is that due to something Renesas broke? Or is that a "feature" of the standard U-Boot Makefile? -- Grant
[U-Boot] Combine zImage and rootfs in single uImage
Currently, I build a linux kernel that contains the root fileystem in the zImage file, when then gets converted into a uImage and booted from NAND flash. This is all working fine, but having the kernel build depend on the rootfs build is a problem. In another mailing list, somebody told me that if I was using U-Boot, I could build the zImage and rootfs separately and then combine them into a single uImage file for distribution. I've been looking through the manual and FAQs, and can't figure out how to do this. I did find a vague reference in one of the Linux kernel docs that some bootloaders will detect any extra bytes after the end of the zImage data and assume that they are a rootfs image. Is that how U-Boot does it? I just cat the ziminage and rootfs.cpio.gz files together and then prepend a uImage header? -- Grant Edwards grant.b.edwardsYow! I selected E5 ... but at I didn't hear Sam the Sham gmail.comand the Pharoahs! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Combine zImage and rootfs in single uImage
On 2012-05-22, Wolfgang Denk w...@denx.de wrote: In message jpgbbm$1hk$1...@dough.gmane.org Grant Edwards wrote: [...] somebody told me that if I was using U-Boot, I could build the zImage and rootfs separately and then combine them into a single uImage file for distribution. The (deprecated) old style way (using legacy image format) is called multi-file images. The modern, recommended way to do things like this is using FIT images. See the respective documentation. Thanks! All our build/update infrastcture expects the uImage legacy image format, so I'm going to stick with the multi-file uImage format for now. FWIW, I couldn't find any documentation for FIT images (it's not mentioned in in either FAQs, Table of Contents, or Index), and various google searches didn't find anything except old mailing list messages. Having the manual chopped up into hundreds of separate web pages makes impossible to search when looking for something. It would be very nice if the Manual was available as a single page. -- Grant Edwards grant.b.edwardsYow! BELA LUGOSI is my at co-pilot ... gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Combine zImage and rootfs in single uImage
On 2012-05-22, Wolfgang Denk w...@denx.de wrote: In message jpghr5$1at$1...@dough.gmane.org you wrote: FWIW, I couldn't find any documentation for FIT images (it's not mentioned in in either FAQs, Table of Contents, or Index), and various google searches didn't find anything except old mailing list messages. First, there is documentation in the doc/ directory - see the doc/uImage.FIT/ directory. Doh! I forgot to look in the source tree. Second, the man page for the mkimage command mentions it (not really extensively, though). Having the manual chopped up into hundreds of separate web pages makes impossible to search when looking for something. It would be very nice if the Manual was available as a single page. It is. It is available as single HTML, PDF and PostScript files. See section 2.3. Availability for respective links. Brilliant! I've been looking for that for a while... Thanks again, -- Grant Edwards grant.b.edwardsYow! Will it improve my at CASH FLOW? gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OT Flashing high volume of devices
On 2010-11-18, Hamilton Vera hamilton.lis...@gmail.com wrote: Hi folks this is probably out off topic, we are happily using uboot in our devices but I am wondering about the procedures to flash/deploy uboot (or any bootloader) in a high scale production environment. Are you guys aware of any documentation or procedure to do that? Send the hex file to the flash distributor and have them do it. -- Grant Edwards grant.b.edwardsYow! I'm meditating on at the FORMALDEHYDE and the gmail.comASBESTOS leaking into my PERSONAL SPACE!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [WIP] tools/env: cleanup host build flags
On 2010-11-10, Wolfgang Denk w...@denx.de wrote: Dear Mike Frysinger, In message 201011100423.13449.vap...@gentoo.org you wrote: - use the cross compiler again (fw_printenv is intended for a hosted environment on the target). the cross-compiler used to create u-boot has no guarantee that it'll produce executables useful for the target OS. often this isnt the case. HOSTCC Really? You mean, you need different tool chains to build U-Boot, the Linux kernel or user space applications? Frankly, I consider those tool chains broken. Sounds like somethings broken to me as well. I've always used the same toolchain for U-Boot, Kernel, Atmel bootstrap, and user-space stuff (vis buildroot). The only think I use a separate toolchain for are Atmel's applets that are part of the SAM-BA utility -- and that's only because I'm too lazy to fix Atmel's Makefiles so they call the compiler with the proper flags. -- Grant Edwards grant.b.edwardsYow! Are we THERE yet? at gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel d...@denx.de wrote: Hi Jef, 10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux. So you do have a network interface on your board? Heck, why don;t you use TFTP then??? I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation. We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :) tftp needs only udp is thus not too complex to implement on bare ethernet. Doesn't our bareboard system doesn't support Ethernet preclude the use of Ethernet (UDP or otherwise)? Maybe you can implement a server on your hardware? What sort of server? -- Grant Edwards grant.b.edwardsYow! If I pull this SWITCH at I'll be RITA HAYWORTH!! gmail.comOr a SCIENTOLOGIST! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel d...@denx.de wrote: I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation. We use tftp in U-Boot exactly because we also do not have a TCP/IP stack :) tftp needs only udp is thus not too complex to implement on bare ethernet. Doesn't our bareboard system doesn't support Ethernet preclude the use of Ethernet (UDP or otherwise)? Yes, sorry. I was mislead by the and not the more efficient FTP used in Linux. The pure mentioning of FTP which does not make any sense without a network port made me read the following statement not close enough. I thought maybe I had lost track of who posted what. :) Maybe you can implement a server on your hardware? What sort of server? It would be a tftp server of course but that is out of the question without a network hardware. Now that you mention it, I have implemented a tftp server for U-Boot. We needed a way to recover bricked units in the field, and there's simply no way we could require out customers to install a tftp server on their machines. Making U-Boot the tftp server and our restore program the client solved several problems. I also find have U-Boot be the server is a lot more convenient for development use. [It also U-Boot commands to be sent via the tftp protocol.] I thought about submitting patches (it's pretty much a stand-alone addition except for 3-4 lines in net.[ch]). But it was made abundantly clear that tftp server code for U-Boot would never be considered -- I was scolded for even asking about it. -- Grant Edwards grant.b.edwardsYow! Life is a POPULARITY at CONTEST! I'm REFRESHINGLY gmail.comCANDID!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Ben Warren biggerbadder...@gmail.com wrote: On 8/23/2010 2:10 PM, Grant Edwards wrote: Now that you mention it, I have implemented a tftp server for U-Boot. We needed a way to recover bricked units in the field, and there's simply no way we could require out customers to install a tftp server on their machines. Making U-Boot the tftp server and our restore program the client solved several problems. I also find have U-Boot be the server is a lot more convenient for development use. [It also U-Boot commands to be sent via the tftp protocol.] I thought about submitting patches (it's pretty much a stand-alone addition except for 3-4 lines in net.[ch]). But it was made abundantly clear that tftp server code for U-Boot would never be considered -- I was scolded for even asking about it. I can see how this could be useful. Please reconsider and we'll try to keep the scolding to a minimum :) OK. I need clean up the sources a little. There's still some debug code that doesn't really need to be there any longer. There's one bit of ugliness on which I could use some advice. The tftp server knows how to write to NAND flash, and uses a RAM buffer the same size as an erase block. Right now I just arbitrarily use a 128K block of RAM starting 256K below text base. That works for my board, but I'm sure isn't the right way to do things. What is the right way for a command to allocate a large, temporary buffer? Increasing the stack/heap size to accomodate a 128K buffer doesn't seem like the right thing to do, nor does statically allocating it. It also only supports a single nand device. In the meantime, here's the document describing how it works: The U-Boot tftp server is run as a normal U-Boot command and uses special filenames to specify source/destination of data and actions to be performed: Destination (used with put or write requests) r...@12345678 Writes receive data into ram starting at address 12345678 (decimal). n...@0x2c0 Writes receive data into nand flash starting at address 0x2C0. Nand will be erased before writing. Writes to nand flash must start on 128K page boundaries and write sizes will be rounded up to the next 4K page boundary. c...@ubootcmdstring Discards any data sent. After transfer completes, interprets 'ubootcmdstring' as if it were entered at the U-Boot command prompt. Command output will appear on normal console device. Source (used with get or read request) n...@0x12345678:4321 Sends 4321 bytes of data from nand flash starting at address 0x12345678. Reads from nand must start on a 512 byte boundary. r...@0x12345678:0x4321 Sends 0x4321 bytes of data from ram starting at address 0x12345678. c...@ubootcmdstring Interprets 'ubootcmdstring' as if it were entered at the U-Boot command prompt and then sends the output of that command as tftp data. If this is used for commands like boot, the transfer will hang because executing the command will terminate U-Boot. Such commands should be executed using a write request rather than a read request. Either Destination or source (either put or get) The following filenames return 0 bytes of data when read from and will discard any data when written to. After the 0 byte data transfer completes, they invoke the actions described. nander...@0x80:0x2 Erases 0x2 bytes of nand flash starting at address 0x80. Erase operation must start on 128K page boundary and erase size must be an integral multiple of 128K. g...@0x12345678 Jump to address 0x12345678. reset@ Reset the board. exitok@ Exit tftp server with success status. exitfail@ Exit tftp server with fail status. When invoking the U-Boot tftp server, an idle-timeout (in seconds) may be specified. If no tftp requests are received within that time, the server will terminate (with a success status). If two arguments are specified, the first is the idle-timeout at startup, and the second is the idle-timeout that is used after the first tftp request has been handled. Timeout values of 0 mean 'run until somebody hits Ctrl-C on the console'. When the tftpserver terminates due to an idle timeout after an initial command has been received, it exits with a failure status. -- Grant Edwards grant.b.edwardsYow! This is a NO-FRILLS at flight -- hold th' CANADIAN
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010-08-23, Detlev Zundel d...@denx.de wrote: Hi Grant, Maybe you can implement a server on your hardware? What sort of server? It would be a tftp server of course but that is out of the question without a network hardware. Now that you mention it, I have implemented a tftp server for U-Boot. Nice job! We needed a way to recover bricked units in the field, and there's simply no way we could require out customers to install a tftp server on their machines. Making U-Boot the tftp server and our restore program the client solved several problems. I also find have U-Boot be the server is a lot more convenient for development use. Yes, I can see that this is very nice in some scenarios. [It also U-Boot commands to be sent via the tftp protocol.] Now this is actually very intersting. I never considered something like this. Of course it has the possibility to do bad things from the outside, but the netconsole code has the same problem. True. In order to be useful for de-brikcing, the tftp server must let outsiders write stuff into flash. Once you've decided to allow that... But unlike netconsole the client side is fully standard. Exactly. Indeed very interesting. Can you pass back results, i.e. the output of an md command? Yes: $ atftp -g -l foo.txt -r 'c...@md.b 0 0x100' 10.0.0.99 $ cat foo.txt : 0d 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea 0010: 05 00 00 ea ac 11 00 00 05 00 00 ea 05 00 00 ea 0020: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea 0030: fe ff ff ea fe ff ff ea fe ff ff ea d4 d0 9f e5 0040: d4 00 9f e5 00 10 90 e5 01 20 a0 e3 02 10 11 e0. .. 0050: 09 00 00 1a c4 00 9f e5 01 19 a0 e3 01 20 a0 e3. .. 0060: 02 10 81 e1 00 10 80 e5 ac 00 9f e5 00 10 90 e5 0070: 01 20 a0 e3 02 10 11 e0 fb ff ff 0a a0 00 9f e5. .. 0080: 03 10 a0 e3 00 20 90 e5 01 20 02 e0 00 10 a0 e3. ... .. 0090: 02 00 51 e1 0e 00 00 1a 01 10 a0 e3 00 20 a0 e3..Q.. .. 00a0: 02 10 81 e1 00 10 80 e5 6c 00 9f e5 00 10 90 e5l... 00b0: 08 20 a0 e3 02 10 11 e0 fb ff ff 0a 64 20 9f e5. ..d .. 00c0: 1a 00 92 e8 04 00 53 e1 04 20 91 34 04 20 83 34..S.. .4. .4 00d0: fb ff ff 3a 34 20 8f e2 18 00 92 e8 00 20 a0 e3...:4 ... .. 00e0: 04 00 53 e1 04 20 83 34 fc ff ff 3a 38 40 9f e5..S.. .4...:8...@.. 00f0: 0f e0 a0 e1 14 ff 2f e1 30 10 9f e5 0f e0 a0 e1../.0... I thought about submitting patches (it's pretty much a stand-alone addition except for 3-4 lines in net.[ch]). But it was made abundantly clear that tftp server code for U-Boot would never be considered -- I was scolded for even asking about it. Maybe I can talk you into posting the patches? It would be an awful waste of effort not to at least post your (working!) implementation here and thus (at least) get it archieved. In Free Software written code always has the potential to change minds ;) OK, I'll clean it up and post it. -- Grant Edwards grant.b.edwardsYow! People humiliating at a salami! gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] handling of bad blocks in nand
On 2010-08-16, Scott Wood scottw...@freescale.com wrote: On Fri, Aug 13, 2010 at 09:22:21PM +, Grant Edwards wrote: At one point in the legacy NAND code, a distinction was made when reading between completely skipping bad blocks, and filling the buffer with zeroes in place of the bad blocks. It looks like .jffs2 or .e would get you zeroes, and .jffs2s or .i would get you block skipping. The zero-fill mode is no longer supported. In 1.3.4, assuming you're not using the legacy NAND code, you need to specify one of .jffs2, .e, or .i to get block skipping. It doesn't matter which one. In current u-boot these suffixes are accepted and ignored as legacy (bad blocks are always skipped), except for jffs2s which apparently never made an appearance outside the legacy code. OK, that clears up quite a bit of my confusion. Yes, it's a bit of a mess. It does appear to be improving. :) 3) In the 1.3.4 source code, there are lots of instances where there are boolean flags with names like jffs2. AFAICT those flags have nothing to do with the JFFS2 filesystem, but simply control whether or not bad flash blocks are skipped during read/write operations. Am I reading the code correctly? The user interface .jffs2 suffix was to indicate bad block skipping, but opts-jffs2 (which is still around) refers to writing JFFS2 cleanmarkers after erasing a block. Thanks, that helps. 4) If in a custom command, I want to read/write a large block of data to/from nand flash while skipping bad blocks what functions do I call? Right now I'm doing something like this: nand_info[0].read(nand_info+0, offset, sizeof(buffer), len, buffer) nand_info[0].write(nand_info+0, offset, bytecount, len, buffer) but, I have a feeling that's not right (though it seems to work, I suspect it's not going to skip bad blocks). You suspect correctly. In current code there is nand_write_skip_bad() and nand_read_skip_bad() in drivers/mtd/nand/nand_util.c. Yup, I found those, and the read version is exactly what I need. I've still got to figure out how to write. The problem is that the data to be written is streaming. I don't know how much there is, and I don't want to allocate arbitrarily large buffers. So I want to write it one erase-block at a time as it arrives. AFAICT nand_write_skip_bad() can't be used in that situation. Since it provides no indication of how many blocks were skipped, I have no way of knowing where the next block should be written. I guess that means I need to use the same lower-level API that is being used by nand_write_skip_bad(). In 1.3.4 use nand_read_opts()/nand_write_opts(). Or convince Atmel to support something more recent. :-) It turns out that Atmel's patches have been merged into the main sources and 2010.6 works fine for the board in question. I don't know why the official Atmel web-page still instructs you to use 1.3.4+patches. -- Grant Edwards grant.b.edwardsYow! I'm encased in the at lining of a pure pork gmail.comsausage!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] handling of bad blocks in nand
On 2010-07-09, Scott Wood scottw...@freescale.com wrote: On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote: If you are putting an MTD filesystem in that partition then the filesystem itself will take care of bad blocks that might occur in the partition during runtime. During the flash programming of this filesystem using nand write.jffs2 (or .e) will skip bad blocks that might occur in the partition. If you are putting an image (kernel or initrd) into the partition then the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite) will handle bad blocks by skipping over them. On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for compatibility only -- bad block skipping is now the default behavior. I'm using 1.3.4 (that's what's supported by Atmel). While that's the current released version, it appears to be over two years old? I've been reading nand flash docs and source code for a while now, and I must admit the more I read the more questions I have. 1) Is there any documentation for the nand commands? There's nothing in the manual, and doc/README.nand appears to be incomplete, and self-contradictory. [There's no mention at all of .e or .i, and there are contradictory descriptions for .jffs2.] 2) Are the behaviors of .jffs2, .e, and .i the same? (It appears so from the source code.) If not how do they differ? 3) In the 1.3.4 source code, there are lots of instances where there are boolean flags with names like jffs2. AFAICT those flags have nothing to do with the JFFS2 filesystem, but simply control whether or not bad flash blocks are skipped during read/write operations. Am I reading the code correctly? 4) If in a custom command, I want to read/write a large block of data to/from nand flash while skipping bad blocks what functions do I call? Right now I'm doing something like this: nand_info[0].read(nand_info+0, offset, sizeof(buffer), len, buffer) nand_info[0].write(nand_info+0, offset, bytecount, len, buffer) but, I have a feeling that's not right (though it seems to work, I suspect it's not going to skip bad blocks). -- Grant Edwards grant.b.edwardsYow! Hello, GORRY-O!! at I'm a GENIUS from HARVARD!! gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] handling of bad blocks in nand
On 2010-08-13, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2010-07-09, Scott Wood scottw...@freescale.com wrote: On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote: If you are putting an MTD filesystem in that partition then the filesystem itself will take care of bad blocks that might occur in the partition during runtime. During the flash programming of this filesystem using nand write.jffs2 (or .e) will skip bad blocks that might occur in the partition. If you are putting an image (kernel or initrd) into the partition then the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite) will handle bad blocks by skipping over them. On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for compatibility only -- bad block skipping is now the default behavior. I'm using 1.3.4 (that's what's supported by Atmel). While that's the current released version, it appears to be over two years old? Never mind. I see that the version naming scheme has changed and what I mistook for datestamped snapshots are actually released versions. That said, 1.3.4 is the most recent version supported by Atmel. So my choices are try to port Atmels patches to a recent version or make do with the nand flash support in 1.3.4. -- Grant Edwards grant.b.edwardsYow! When this load is at DONE I think I'll wash it gmail.comAGAIN ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to download image to U-Boot
I've read through the U-Boot manual and FAQ, but I still haven't figured out how one downloads via the network an image to a board running U-Boot. Previous projects have used RedBoot, and it provided a couple different mechanisms: 1) Telnet to the board and download an image (binary or S-Record) using the x/y-modem protocol over the telnet connection. 2) Download a binary image directly using a TCP connection to a dedicated port. Both of these methods would work through firewalls and WAN connections (even through satellite links), and could easily be automated in an updater utility that is then provided to customers to update images in flash. I can't seem to find out how one accomplishes the same task using U-Boot. The only method I can figure out involve setting up a TFTP server (which is not going to be acceptible to customers), and then typing a series of commands while plugging into a serial console (also not going to be acceptible to customers). The requirement is to update the image using just the network and a user-space application that doesn't require any system privledges to run. I found mention of netconsole, but I don't see how it's useful since you have to know a-priori the address of the machine from which you want to use it. It would seem that you have to force the customer to change the IP address of their machine (not acceptible). -- Grant Edwards grante Yow! Thank god!! ... It's at HENNY YOUNGMAN!! visi.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to download image to U-Boot
On 2009-11-17, Wolfgang Denk w...@denx.de wrote: In message hdurn4$2b...@ger.gmane.org you wrote: I've read through the U-Boot manual and FAQ, but I still haven't figured out how one downloads via the network an image to a board running U-Boot. Previous projects have used RedBoot, and it provided a couple different mechanisms: There are many different ways in U-Boot - over serial line, over Ethernet using TFTP or NFS, from a number of different storage devices like MMC/SDCard, USB Mass Storage Devices, harddisks, ... Both of these methods would work through firewalls and WAN connections (even through satellite links), and could easily be automated in an updater utility that is then provided to customers to update images in flash. You don't have much of authentication in such an envrionment True. which makes it unacceptable even for mimimum security envrionments. False. Almost all of our customers find it acceptible and it has never proven to be a problem in the 10 years we've been shipping product. For the few customers who do use the products on an usecured network, the update mechanisms can be secured. If you need such a szenario, then boot into a (minimal) Linux kernel, and run the update in a real OS. So the answer is U-Boot doesn't support the sort of update mechanism I'm talking about. That's fine. There's no reason to get rude and insulting about it. I can't seem to find out how one accomplishes the same task using U-Boot. The only method I can figure out involve setting up a TFTP server (which is not going to be acceptible to customers), and then typing a series of commands while plugging Why would this not be acceptable? We can't require that the box is physically accessible or that the customer have a serial port. Alternatively, you can use NFS (but I guess you will argument that setting up a NFS server is also not acceptable). I'm afraid it isn't. into a serial console (also not going to be acceptible to customers). The requirement is to update the image using just Ah, also not acceptable. I'm sorry, what isn't acceptible? Of course you can kill any system by just excluding all available features as not acceptable - without giuving reasons for this, of course. Note that this works fine for many, many others, so you might want to ask yourself if your requirements are acceptable. My opinions have nothing to do with it, and they're not my requirements. I'm perfectly happy setting up a TFTP server and using a serial console. Our customers, however, are neither willing or able to up special servers in order to update the firmware in our products. I found mention of netconsole, but I don't see how it's useful since you have to know a-priori the address of the machine from which you want to use it. It would seem that you have to force You don't have to. You can use broadcasts. That's not going to work through firewalls. the customer to change the IP address of their machine (not acceptible). Why am I not surprised that this is not acceptable, either? Because it's not something our customers are willing to do. I take it that your position is that everying that U-Boot doesn't support is worthless and stupid as are people who desire or currently use such features. Thanks. -- Grant Edwards grante Yow! Am I SHOPLIFTING? at visi.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
