From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Updegraff Date: Fri, 05 Jan 2007 16:27:12 -0600 Subject: [U-Boot-Users] do_bootm_linux OF_FLAT_TREE In-Reply-To: <20070105211206.CB640353C96@atlas.denx.de> References: <20070105211206.CB640353C96@atlas.denx.de> Message-ID: <459ED0C0.6020108@cray.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de W. hmm.. I kind was off on the tangent that I thought Mr. Gala had suggested of having some way to "know" what kind of images were in that MULTI (how? mini-headers? magic-bytes?) and cope.. But maybe an agreed-upon order is ok too. But is friday.. brain shutting down... > Dear David, > > in message <459E6DC3.9040900@cray.com> you wrote: >> Kumar Gala wrote: > ... >>> When I implemented this I felt that it was an all or nothing situation. >>> Either you specified the memory locations of the kernel, initrd, and dtb >>> or you used a single MULTI image. > > That was what I had in mind, too, when we discussed this. > > I have to admit that I missed this special case, too. > >> Right... but the _assumption_ everywhere in *_bootm seems to be that >> MULTI = kernel + initrd > > Ummm... this may look like an assumption, but it ain't so. It's just > that this was the only useful application of multifile images so far. > My intention however has always been to extend this if it should ever > be needed - like now. > >> so my view would be to not introduce another [unfounded?] assumption >> that .. eg. MULTI = kernel + initrd + dtb. So; yes; it'd be maybe nice > > That's what was discussed, and agreed on, before. > >> to have the picking apart of MULTI off in its own func so its done >> consistently.. or, at a cost of more duct-tape, but less overall >> impact-full might be enclosed patch. >> >> I dunno; still hoping & searching for a less-duct-tape solution. > > Maybe we should make this duplicated code a separate function so we > can use something like "len = find_initrd (hdr, &data);" or so? > > > Best regards, > > Wolfgang Denk >