From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 10 Nov 2011 19:07:39 +0100 Subject: [U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD In-Reply-To: <4EBC11CE.1050202@nvidia.com> References: <1320860840-6347-1-git-send-email-swarren@nvidia.com> <201111101847.17687.marek.vasut@gmail.com> <4EBC11CE.1050202@nvidia.com> Message-ID: <201111101907.39470.marek.vasut@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > On 11/10/2011 10:47 AM, Marek Vasut wrote: > >> On 11/10/2011 10:01 AM, Marek Vasut wrote: > >>>> On 11/10/2011 02:58 AM, Marek Vasut wrote: > >>>>>> [Description of IH_TYPE_KERNEL_ANYLOAD] > >>>>> > >>>>> just a silly question, but didn't we agree on cmd_bootz? Or is this > >>>>> unrelated ? > >>>> > >>>> bootz did seem to be agreed upon initially, but Wolfgang's most recent > >>>> response suggested that a new IH_TYPE would be acceptable, and it's a > >>>> lot less code to implement. At a later point, bootz could still be > >>>> implemented if desired. > >>> > >>> Well DAMN. I think I'll probably implement bootz, because it seems > >>> superior solution which I DID NEED for one of my devices for a while > >>> now (if noone is working on it already). I can't say what ETA will be > >>> on that, maybe next week, maybe two weeks. > >> > >> Out of curiosity, why doesn't this bootm feature work for you? > >> Admittedly you still need to wrap the zImage inside a uImage, but I > >> don't think that's insurmountable? Aside from that, doesn't it work > >> exactly like a bootz command would? > > > > Do you still have those +12bytes (sizeof(uImage header)) offset there? > > I don't like it. > > The uImage file itself certainly includes the uImage header. > > The code in my latest patches should be pointing images.os.load right at > the image start itself (i.e. pointing past the header), so I don't think > there's any incorrect offset within the code. This was really just a bug > in the "-1 load address" patches I posted anyway. > > > Also, I think using zImage might be plain easier. > > Well, admittedly it's slightly simpler not to wrap zImage in uImage, > since there's no need to run mkimage. However, with this new IH_TYPE, > all the mkimage parameters can be hard-coded (there's no need to specify > any real value for the addresses; just use 0), so the command-line is > pretty simple. Besides, I imagine the kernel uImage target can be > updated (or a new one added) to continue to do this for you. > > I did consider that not running mkimage at all would be simpler, but > there are other places mkimage would still be needed anyway: > > a) Any initrd would still need to be wrapped in a uImage for bootm to > recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I > imagine that same raw initrd recognition code could just as easily be > applied to bootm. Well if you want an image where you have kernel+initrd, why not use initramfs ? > > b) The distro will most likely want to specify either the entire Linux > command-line, or at least something to append to it. I imagine this will > work by the distro creating a uImage-wrapped U-Boot script e.g. > /boot/script.uimg. Creating that script would require mkimage too. > Perhaps again U-Boot could be modified to support loading scripts from > disk and executing them without requiring a uImage header though. > > So, I don't think eliminating mkimage entirely is all that likely. And > as such, using mkimage for the kernel itself doesn't seem like a big deal. Hm, isn't FDT supposed to contain the command line now ? > > Still, I'm not a distro vendor, so I don't know what their feelings are > on this topic. It's good to discuss stuff actually! It only mustn't turn into flamewar ;-) M