Re: [RFC] Kbuild support for ARM FIT images
On Fri 2013-02-22 08:00:44, Olof Johansson wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. Not sure I agree here: 1) zImage was designed to boot from floppy, without any kind of bootloader on i386 2) There are no distributions on many embedded systems. And no good place where to store the scripts. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: On Fri 2013-02-22 08:00:44, Olof Johansson wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. Not sure I agree here: 1) zImage was designed to boot from floppy, without any kind of bootloader on i386 zImage on x86 != zImage on ARM. They only share the fact that they're both compressed and self-extracting. ARM has never supported any kind of floppy based boot - mainly because floppies have never been executable like they are on x86; all that previous boot loaders ever did was load the kernel into RAM using some method and call address 0, with a data structure (formerly struct params, later atags) at a fixed address, later passing that address to the kernel. The best floppies got was being able to run a script or load an executable off the floppy under the ROM'd OS, and our zImage itself doesn't fit the format required for that. Our zImage has always been just a pure straight binary compressed kernel format. Nothing more. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Mon 2013-03-18 16:44:26, Russell King - ARM Linux wrote: On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: On Fri 2013-02-22 08:00:44, Olof Johansson wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. Not sure I agree here: 1) zImage was designed to boot from floppy, without any kind of bootloader on i386 zImage on x86 != zImage on ARM. They only share the fact that they're both compressed and self-extracting. ARM has never supported any kind of floppy based boot - mainly because floppies have never been executable like they are on x86; all that previous boot loaders ever did was load the kernel into RAM using some Yes, I know. That's why I said on i386. What I wanted to say is that kernel build traditionaly produced something useful, something bootloader can actually boot. Currently, make uImage produces u-boot image. Please keep that capability. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: What I wanted to say is that kernel build traditionaly produced something useful, something bootloader can actually boot. Currently, make uImage produces u-boot image. Please keep that capability. Unfortunately, there is a fundamental problem with uImage. It encodes the load address, and that is utterly incompatible with the goal of having a kernel image which boots on multiple platforms. uImage isn't going anywhere for the time being, but you will find that: a) recent kernels will just wrap the zImage without a DTB, so appended DTBs can't be used with it b) it won't work with MULTIPLATFORM-enabled kernels, unless you provide make with a LOADADDR= argument to tell it where the uImage is to be loaded - which is platform specific. (b) fundamentally can't be solved in kbuild. If you want to use uImage with multiple platforms from the same zImage, then you need to generate multiple uImage files with different load addresses. That's purely - and solely - down to the dysfunctional uImage format. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote: On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: What I wanted to say is that kernel build traditionaly produced something useful, something bootloader can actually boot. Currently, make uImage produces u-boot image. Please keep that capability. Unfortunately, there is a fundamental problem with uImage. It encodes the load address, and that is utterly incompatible with the goal of having a kernel image which boots on multiple platforms. uImage isn't going anywhere for the time being, but you will find that: a) recent kernels will just wrap the zImage without a DTB, so appended DTBs can't be used with it b) it won't work with MULTIPLATFORM-enabled kernels, unless you provide make with a LOADADDR= argument to tell it where the uImage is to be loaded - which is platform specific. (b) fundamentally can't be solved in kbuild. If you want to use uImage with multiple platforms from the same zImage, then you need to generate multiple uImage files with different load addresses. That's purely - and solely - down to the dysfunctional uImage format. I know. uImage is not perfect. But solution should be adopt a better format (ARM FIT?), not drop support for making useful images altogether as Olof proposed before. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
Dear Russell, In message 20130318175746.gj30...@n2100.arm.linux.org.uk you wrote: Unfortunately, there is a fundamental problem with uImage. It encodes the load address, and that is utterly incompatible with the goal of having a kernel image which boots on multiple platforms. I'm not sure if you are aware that U-Boot supports uImages that can be run from _any_ load address (using the IH_TYPE_KERNEL_NOLOAD image type). If anybody was willing to keep uImage support in the kernel this would probably be a convenient way to go. But in any case, the uImage format is deprecated. Support for FIT images was added more than five years ago, and new developments should rather focus on supporting these. 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: w...@denx.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 4:37 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. Sorry for hopping in late as I have been travelling. Guess much has been said, but for courtesy sake till dts/u-boot build support is dropped, would you consider accepting a simple extension to mkuboot.sh with minimal Kbuild changes? I can promise there will be quite a few users. Lots of folks want embedded device trees and there are already out of tree hacks floating as you know that do this. FIT approach to this is more cleaner I feel. Let me know what you can do. Thanks, Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. Note that FIT images are relatively old (docs date back to March 2008). This is more of another effort to try and update what the kernel uses. And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. Well, once the device trees move to some external location, this script could also easily move out with it. And I'd hope there'd be interest out in the rest of the world for a single file boots on multiple platforms image format. If the ability to do this was actually well known, it might even stop people from re-inventing the wheel for fun (re-inventing due to design problems with the previous wheel is acceptable). We're just about to make a lot of folks lives harder (whatever the userbase is for omap2plus_defconfig). How much time do we want to spend offering up alternatives? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJh84AAoJENk4IS6UOR1W9BEP/3rxNUz9dNZ3PwfVBuXT6LiX P6ANVDFg9uZTWTaoLgcTjXkmvexjpaeZz+5T0TOErDf/YoaOVqjfhVlZE82VE010 t7CC23cTGCOo7q/ofJalzUzhdZE2/DLsGXNdz4wi6f8N0v46DNdAuolUqgyYXjvg 3rKK7G3ZzWUrmhkILfsZ/8XvbQ+rUDlMDajUnr0RnarsxWbM6KkVPRbCzUrEfsZA a4AKdg5msl2XxtgNlcOwvb4LCZXCmdRdulkGzf45AhyUpNGkgFYrCu5mlFvjYy9U JGCw/2V9IqXqsN0hoBDxgRHvnN5o+EJasPZPxY2MMSRAr2fkhGPMicYW0jvo/t9G DzNfQ2qZiHHY5SzuBzLh/ejRdviGm+SRrQTI2MSKEMixvUgsCL43UCBaMn09fv5o kRjNLDvi0WeQ/T9PPF3xcbMQRlATW5VmBt8ZJ/OKmptjRAay3Eq44a2J1Bb89KGV iuO7hxt1Yuo/Wc/6gghcJLDxn5EuE5oES/WLhmzEQE6c9u2xM5Ygmf2utiy4JZTo Y9iilnP7mQ51TbV7cXtwLvLaR6rJHW3XIHinDHQVK26fACtAHRUoNzRI86HQnNQx tnuDJPQcHUEWkG6aq9ikvxWx1j692lKpmPlVXZ7QoYWCdYdAVtpn8OP7iWih42XW 9+Gkuwfc2vaZfvC1LkGu =iUUO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 11:26 PM, Stephen Warren wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello, I've been spinning some work-in-progress patches for FIT
build support in the kernel. With the move to multiplatform
support on OMAP, I feel it is a good time to add FIT support,
also looking at the proliferating number of dtbs, as it is a nice
way
To my mind, FIT is pointless. And forcing the kernel build process
to create bootloader-specific files doesn't seem like a good idea.
Doing so would require pulling in even more outside tools into the
kernel build flow.
No, it requires no more tools than we have today. It's still just
mkimage and a device tree file.
All you need is to copy the zImage and any relevant .dtb files
into /boot, and have U-Boot load the relevant .dtb file by
constructing the filename as roughly ${soc}-${board}.dtb, then use
the bootz command to boot it. You can have a completely generic
boot.scr (or built-in script).
Note you still have to copy N dtb files into the filesystem. Or one
file, the FIT image.
Note: Not all (many?) U-Boot support FIT anyway, so you'd need to
flash a new U-Boot to support FIT, so you may as well just flash a
new U-Boot that implements the ${soc} and ${board} variables
instead. IIRC, there may also be a ${boardname} or similar that's
like ${board}, but represents the runtime-detected board for when
one U-Boot build actually supports multiple different boards.
And enable bootz as well. Just about as many boards enable that as do
FIT. And FIT has been around for years, bootz not so. So in theory
folks with old/odd boards that didn't bother to get mainlined in
U-Boot could still have FIT support added, easily.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRJiE9AAoJENk4IS6UOR1WmVsP/2FEIJVDkB1Aefl5Zs0c1pGa
FjhDKASnsu8SqjHfjP6o0xkbxhdQHQw0AzDGOlGfbkDk7SUVLmyYkI8WeeZ/O6dB
cGW7zTV1TXU+Hjl3VqDBID7cskCANNn35fcbba5Q9+0Lo+KD39Jme63hilu2EBfj
njFbC55+U4yOY+uRD99w32GMd+yHaOL5yTQICmMasBuwsRfP/vrPIy9LBQ7z73Xd
f9/D0tfz1O5/QHxkn41zHfHDKoTpa3fbDcp3d/jgPPQK682nN38RD48s4AeC/1m4
GsnHEY3ykMIAPV49dEBm3ebC0HavIZ5sB5JlQh09Hk7kPQ4yJJgwpLzhxhByN0LR
3s5OgexNAuREtJWbOpghwS2d2GajNSPy845TmznkZI9gTWUi5PhA/6h+JQVm7/Ls
K515cs4TSvAEHUMP60AtvSi8Axe6nnDAJcTpPEeQyskCR2jGAmt80XsioJ0fprls
cZZr7shkarqdQbFjSLpvIFVSo0//xPq4OaLqoKInxmDQEYNmzCcKsbB2LlXywq7l
Tr6vrxe9O2BhJhXpi1NNBlJsOmII3Ft6/0MKKer8E3poITo6TKbRQG2O17lR49JP
RRbIKDB8X1wM2YybHHQaGwOTnkjZSGsYHDi9qKuK27UA27qGbu/FDmfHYPHsNpBo
ziTmDL5uI7rFQEkHiYVd
=M25C
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote: On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. Note that FIT images are relatively old (docs date back to March 2008). This is more of another effort to try and update what the kernel uses. So it's five years old and people haven't been that interested in it so far. That speaks volumes... And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. Well, once the device trees move to some external location, this script could also easily move out with it. And I'd hope there'd be interest out in the rest of the world for a single file boots on multiple platforms image format. We've had that for the last 18 years. It's called zImage. The real problem is that uboot has been particularly difficult over this - uboot and _only_ uboot wants to use its own special file formats. No other boot loader on ARM has ever wanted this stuff - everything else has been totally happy with zImage. uboot even now supports zImage through the bootz command, so it now supports the native format used on ARM. We're just about to make a lot of folks lives harder (whatever the userbase is for omap2plus_defconfig). How much time do we want to spend offering up alternatives? We're about to make it harder how? By forcing them to use DT blobs? Or by forcing them to have to use the combined zImage + DT format because their boot loaders are soo broken that they can't deal with multiple images? Yes, things have become a _little_ harder since OMAP has switched to multiplatform, but it really isn't that bad. My build and boot test system still works, and it uses uImage for all the OMAP platforms. You just have to give the right LOADADDR= argument to the kernel to make the uImage generation work again. Sure, the resulting uImage can't be loaded at a different address, but you if you need to change that, you can quite easily move the existing uImage out and re-run make ARCH=arm uImage LOADADDR=something else and hey presto, you end up with the uImage generated for a different address. But: we wouldn't be in this situation if it weren't for these absurd uboot uImage formats in the first place. Or even be needing this FIT stuff if zImage was just used directly. uboot dug _itself_ into this hole. It's uboot's problem. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote: On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote: On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way I'm not looking to add yet another crappy uboot image format to the kernel just for the hell of uboot. Note that FIT images are relatively old (docs date back to March 2008). This is more of another effort to try and update what the kernel uses. So it's five years old and people haven't been that interested in it so far. That speaks volumes... No, it was just rejected a while back over in PowerPC-land by gcl (whom I talked with, but won't put words in his mouth here) and no one thought about bringing it forward again until now. And don't think that the dtbs in the kernel are going to stay there. The longer term plan is for them to end up in an external git tree, entirely separate from the kernel source. So anything that ties them with the kernel build process will ultimately have to be removed again. Well, once the device trees move to some external location, this script could also easily move out with it. And I'd hope there'd be interest out in the rest of the world for a single file boots on multiple platforms image format. We've had that for the last 18 years. It's called zImage. The real problem is that uboot has been particularly difficult over this - uboot and _only_ uboot wants to use its own special file formats. No other boot loader on ARM has ever wanted this stuff - everything else has been totally happy with zImage. uboot even now supports zImage through the bootz command, so it now supports the native format used on ARM. We're just about to make a lot of folks lives harder (whatever the userbase is for omap2plus_defconfig). How much time do we want to spend offering up alternatives? We're about to make it harder how? By forcing them to use DT blobs? Or by forcing them to have to use the combined zImage + DT format because their boot loaders are soo broken that they can't deal with multiple images? None of that. We're making it harder since most folks don't have a board with 'bootz' built-in and the 'uImage' target doesn't build now (unless, yes, you pass LOADADDR to make) so they either format it by hand (/ adjust their local scripting) or do what you're doing. Yes, things have become a _little_ harder since OMAP has switched to multiplatform, but it really isn't that bad. My build and boot test system still works, and it uses uImage for all the OMAP platforms. You just have to give the right LOADADDR= argument to the kernel to make the uImage generation work again. Sure, the resulting uImage can't be loaded at a different address, but you if you need to change that, you can quite easily move the existing uImage out and re-run make ARCH=arm uImage LOADADDR=something else and hey presto, you end up with the uImage generated for a different address. But: we wouldn't be in this situation if it weren't for these absurd uboot uImage formats in the first place. Or even be needing this FIT stuff if zImage was just used directly. FIT isn't required. FIT is just trying to offer a nice usability thing to folks. A point of device trees is a single image works in a lot of places. FIT gives you a single file works in a lot of places. uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJip6AAoJENk4IS6UOR1W6CUP/1oxzA4MBpkC7sFlvRUE+jLk aqF8FpsfkosN5oz1WaIAH3lV0AAUIBRLso7SfDQ+H4deCDp2zy3LZ16+jMe+hUIU h4SReKujxR1oXUGYTYy/og6t0pN19f+KF79I6zEqfySOE4YL/BcDhqNwWTOQ2q8o q8+w2Ez1uQTQmQu1IcQoZ7fZ41XPMfeH6zr/19oo7NC27oyiR7b230w1xiY4YIHL Wry2tYad7XyP7lEJPanSzETWoZSS6O3uYEDKJhM98ucauJPfcVZ1GUWt4I2Q2G/3 qLKt0SVPY2kDDD6vDiCXZ8IPpxoD7Cq/tV0DRYniI9nkvoeBloZCvIQ3ZYmO/+qE uo2Z1Pm/iRkLCLmDTOhruP6OtGepWhUvCBsSR1GoEd/sh2p93khUqwe0u6M4xr4N aUM3Fngbjf9Mbl4gKgOHVksWIXQU0kCD09aH04YlSi1Ky5fmdO1tgHkrYoZM52WC xMWbzez8A3OS9hb/5WhzrEhk8OOHH1l8igOdDJ2R/grDTWpSYZ7haMMghJE41fBo ybv2QvKF6IYk1E8UsuON39uNS803AH5AwNtA1azzp/MwwYjiybxBTBoaOW4ID43R YQ26YFNPOCvuw/ib9FkNBQrx3kt6Fu79fkyxHHDPmpxX3HVoxNDtmmm5lPymwKOu 4V0IHuD68nhvyaA1RPGp =O7jS -END PGP SIGNATURE- -- To unsubscribe from this
Re: [RFC] Kbuild support for ARM FIT images
(Dropped uboot mailing list because it constantly holds my mails for moderation.) On Thu, Feb 21, 2013 at 09:08:58AM -0500, Tom Rini wrote: On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote: We're about to make it harder how? By forcing them to use DT blobs? Or by forcing them to have to use the combined zImage + DT format because their boot loaders are soo broken that they can't deal with multiple images? None of that. We're making it harder since most folks don't have a board with 'bootz' built-in and the 'uImage' target doesn't build now (unless, yes, you pass LOADADDR to make) so they either format it by hand (/ adjust their local scripting) or do what you're doing. And adjusting their process to pass an additional argument to the kernel make is too difficult? So instead we have to change the kernel makefiles and scripting to create yet another uboot specific format, which is going to need them to edit their scripts in a much more invasive way _anyway_? or do what you're doing - oh you mean, adding an additional column to the database configuration, digging out from the kernel git history what the load addresses should be, updating the database tables with that, editing the build system scripts to extract this new column from the database, and pass it into make... yes, complicated isn't it. Didn't take long to sort out though, and didn't require a load of new file formats to fix. Yes, things have become a _little_ harder since OMAP has switched to multiplatform, but it really isn't that bad. My build and boot test system still works, and it uses uImage for all the OMAP platforms. You just have to give the right LOADADDR= argument to the kernel to make the uImage generation work again. Sure, the resulting uImage can't be loaded at a different address, but you if you need to change that, you can quite easily move the existing uImage out and re-run make ARCH=arm uImage LOADADDR=something else and hey presto, you end up with the uImage generated for a different address. But: we wouldn't be in this situation if it weren't for these absurd uboot uImage formats in the first place. Or even be needing this FIT stuff if zImage was just used directly. FIT isn't required. FIT is just trying to offer a nice usability thing to folks. A point of device trees is a single image works in a lot of places. FIT gives you a single file works in a lot of places. Well, FIT isn't everywhere either. So really that argument doesn't stand for the same reasons that bootz support isn't everywhere either. My SDP4430's uboot provided by TI uses uboot 1.1.4. Therefore, it doesn't support FIT, nor bootz - only uImage. uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. FIT just propagates the boot loader specific file format absurdity which was a mistake when uImage came along... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On 02/21/2013 09:37 AM, Russell King - ARM Linux wrote: (Dropped uboot mailing list because it constantly holds my mails for moderation.) On Thu, Feb 21, 2013 at 09:08:58AM -0500, Tom Rini wrote: On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote: We're about to make it harder how? By forcing them to use DT blobs? Or by forcing them to have to use the combined zImage + DT format because their boot loaders are soo broken that they can't deal with multiple images? None of that. We're making it harder since most folks don't have a board with 'bootz' built-in and the 'uImage' target doesn't build now (unless, yes, you pass LOADADDR to make) so they either format it by hand (/ adjust their local scripting) or do what you're doing. And adjusting their process to pass an additional argument to the kernel make is too difficult? So instead we have to change the kernel makefiles and scripting to create yet another uboot specific format, which is going to need them to edit their scripts in a much more invasive way _anyway_? or do what you're doing - oh you mean, adding an additional column to the database configuration, digging out from the kernel git history what the load addresses should be, updating the database tables with that, editing the build system scripts to extract this new column from the database, and pass it into make... yes, complicated isn't it. Didn't take long to sort out though, and didn't require a load of new file formats to fix. Shrug. Time will tell if everyone adopts as easily as you have. Yes, things have become a _little_ harder since OMAP has switched to multiplatform, but it really isn't that bad. My build and boot test system still works, and it uses uImage for all the OMAP platforms. You just have to give the right LOADADDR= argument to the kernel to make the uImage generation work again. Sure, the resulting uImage can't be loaded at a different address, but you if you need to change that, you can quite easily move the existing uImage out and re-run make ARCH=arm uImage LOADADDR=something else and hey presto, you end up with the uImage generated for a different address. But: we wouldn't be in this situation if it weren't for these absurd uboot uImage formats in the first place. Or even be needing this FIT stuff if zImage was just used directly. FIT isn't required. FIT is just trying to offer a nice usability thing to folks. A point of device trees is a single image works in a lot of places. FIT gives you a single file works in a lot of places. Well, FIT isn't everywhere either. So really that argument doesn't stand for the same reasons that bootz support isn't everywhere either. My SDP4430's uboot provided by TI uses uboot 1.1.4. Therefore, it doesn't support FIT, nor bootz - only uImage. Because I can easily see TI having given you an odder than usual board, I won't suggest you simply run mainline U-Boot instead (and enable CONFIG_CMD_BOOTZ). I was wondering how old what we gave you was tho, sigh. uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. FIT just propagates the boot loader specific file format absurdity which was a mistake when uImage came along... Would you feel better about it if something else parsed FIT too? -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
Dear Russell, In message 20130221134656.gc17...@n2100.arm.linux.org.uk you wrote: Note that FIT images are relatively old (docs date back to March 2008). This is more of another effort to try and update what the kernel uses. So it's five years old and people haven't been that interested in it so far. That speaks volumes... Well, your attitude to (not) accept anything like that is well known; there have been few previews attempts, which have all been rejected in basicly the same way. But now the situation has changed - multiplatform support adds a number of use cases where this feature comes in handy, so it pops up again. 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: w...@denx.de The aim of science is not to open the door to everlasting wisdom but to set a limit on everlasting error. - Bertolt Brecht -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
[uboot list deleted again] On Thu, Feb 21, 2013 at 06:37:07PM +0100, Wolfgang Denk wrote: Dear Russell, In message 20130221134656.gc17...@n2100.arm.linux.org.uk you wrote: Note that FIT images are relatively old (docs date back to March 2008). This is more of another effort to try and update what the kernel uses. So it's five years old and people haven't been that interested in it so far. That speaks volumes... Well, your attitude to (not) accept anything like that is well known; there have been few previews attempts, which have all been rejected in basicly the same way. _My_ attitude? I'll point out something fundamental here: _our_ kernels native format has not changed over the last 15+ years, and continues to work everywhere where uboot is not involved, and continues to work where uboot is involved provided its wrapped up in silly uboot formats. That means we designed it right back in the early days. The fact that uboot has to reinvent the wheel shows that there were wrong design decisions made that did not cater for the situations that people encountered in the future. Now, as for have all been rejected in basic_al_ly the same way that's not true. What you'll notice is that there's been discussions over the years about FIT, which never went anywhere for various reasons (some of them I was not involved with.) And during those discussions, uboot's continued refusal to use the native zImage format ended up getting fixed by those who raised (and continue to raise) concerns about uboots fixation with its file formats and the built-in restrictions of them. But now the situation has changed - multiplatform support adds a number of use cases where this feature comes in handy, so it pops up again. No, the situation hasn't changed. We're still talking about booting a kernel image in several platforms. That's been the situation since the 1990s. And boot loaders from the 1990s and early 2000s have been able to do this _long_ before uboot. What's changed is the number of platforms, and the apparant acceptance of uboot as the official boot loader because it's seen as having its own format integrated into the kernel itself. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On 02/21/2013 12:15 AM, Joel A Fernandes wrote: On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/20/2013 06:37 PM, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way To my mind, FIT is pointless. And forcing the kernel build process to I don't think so, there are many usecases for FIT and cleanly embedding DTBs is a common usecase, (along with stronger checksums, compression). That is also the basis of my ELC talk tomorrow morning ;-) You could peruse the slides at, http://wwwelinux.org/Fit-boot to get a better understanding of what FIT solves. With the move to multiplatform kernels, it is quite a logical next step to add this support to the kernel build. create bootloader-specific files doesn't seem like a good idea. Doing so would require pulling in even more outside tools into the kernel build flow. As for pulling additional tools, dtc is already a part of the kernel so the idea is to use existing tools. Well, dtc won't be part of the kernel build process for ARM at least once the device tree files are move outside the kernel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On 02/21/2013 06:29 AM, Tom Rini wrote:
On 02/20/2013 11:26 PM, Stephen Warren wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello, I've been spinning some work-in-progress patches for
FIT build support in the kernel. With the move to
multiplatform support on OMAP, I feel it is a good time to add
FIT support, also looking at the proliferating number of dtbs,
as it is a nice way
To my mind, FIT is pointless. And forcing the kernel build
process to create bootloader-specific files doesn't seem like a
good idea. Doing so would require pulling in even more outside
tools into the kernel build flow.
No, it requires no more tools than we have today. It's still just
mkimage and a device tree file.
mkimage isn't required today, if you use the bootz target rather than
bootm. Using bootz is a huge improvement since you don't need to use
bootloader-specific tools to create the kernel boot images; just slap
them on the disk, and you're done. Nothing could be simpler.
All you need is to copy the zImage and any relevant .dtb files
into /boot, and have U-Boot load the relevant .dtb file by
constructing the filename as roughly ${soc}-${board}.dtb, then
use the bootz command to boot it. You can have a completely
generic boot.scr (or built-in script).
Note you still have to copy N dtb files into the filesystem. Or
one file, the FIT image.
But you have to generate the FIT image that packages all the files
together.
The long-term goal for device tree is to move the *.dts files out of
the kernel source. It's unclear if there will be some single central
repository for them, or whether vendors will host their own repository
just for their own boards. The latter would probably scale the best.
Having separate distro packages for different vendors' or different
SoCs' device tree would also scale the best; forcing usage of FIT
where everything gets merged together doesn't interact well with that.
Note: Not all (many?) U-Boot support FIT anyway, so you'd need
to flash a new U-Boot to support FIT, so you may as well just
flash a new U-Boot that implements the ${soc} and ${board}
variables instead. IIRC, there may also be a ${boardname} or
similar that's like ${board}, but represents the runtime-detected
board for when one U-Boot build actually supports multiple
different boards.
And enable bootz as well. Just about as many boards enable that as
do FIT. And FIT has been around for years, bootz not so. So in
theory folks with old/odd boards that didn't bother to get
mainlined in U-Boot could still have FIT support added, easily.
I guess that's true, but enabling bootz in a U-Boot ends up bringing
in a lot less conceptual complexity, and I would guess a bit less code
too.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On 02/21/2013 01:58 PM, Stephen Warren wrote: On 02/21/2013 12:15 AM, Joel A Fernandes wrote: On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/20/2013 06:37 PM, Joel A Fernandes wrote: Hello, I've been spinning some work-in-progress patches for FIT build support in the kernel. With the move to multiplatform support on OMAP, I feel it is a good time to add FIT support, also looking at the proliferating number of dtbs, as it is a nice way To my mind, FIT is pointless. And forcing the kernel build process to I don't think so, there are many usecases for FIT and cleanly embedding DTBs is a common usecase, (along with stronger checksums, compression). That is also the basis of my ELC talk tomorrow morning ;-) You could peruse the slides at, http://wwwelinux.org/Fit-boot to get a better understanding of what FIT solves. With the move to multiplatform kernels, it is quite a logical next step to add this support to the kernel build. create bootloader-specific files doesn't seem like a good idea. Doing so would require pulling in even more outside tools into the kernel build flow. As for pulling additional tools, dtc is already a part of the kernel so the idea is to use existing tools. Well, dtc won't be part of the kernel build process for ARM at least once the device tree files are move outside the kernel. And at that point it would also make sense to move any other help folks get things going tooling happens to exist out of the kernel. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time to add FIT support, also looking at the proliferating number of
dtbs, as it is a nice way
To my mind, FIT is pointless. And forcing the kernel build process to
create bootloader-specific files doesn't seem like a good idea. Doing so
would require pulling in even more outside tools into the kernel build flow.
All you need is to copy the zImage and any relevant .dtb files into
/boot, and have U-Boot load the relevant .dtb file by constructing the
filename as roughly ${soc}-${board}.dtb, then use the bootz command to
boot it. You can have a completely generic boot.scr (or built-in script).
Note: Not all (many?) U-Boot support FIT anyway, so you'd need to flash
a new U-Boot to support FIT, so you may as well just flash a new U-Boot
that implements the ${soc} and ${board} variables instead. IIRC, there
may also be a ${boardname} or similar that's like ${board}, but
represents the runtime-detected board for when one U-Boot build actually
supports multiple different boards.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
Hello,
I've been spinning some work-in-progress patches for FIT build support
in the kernel.
With the move to multiplatform support on OMAP, I feel it is a good
time to add FIT support, also looking at the proliferating number of
dtbs, as it is a nice way
To my mind, FIT is pointless. And forcing the kernel build process to
I don't think so, there are many usecases for FIT and cleanly
embedding DTBs is a common usecase, (along with stronger checksums,
compression). That is also the basis of my ELC talk tomorrow morning
;-)
You could peruse the slides at, http://wwwelinux.org/Fit-boot to get a
better understanding of what FIT solves. With the move to
multiplatform kernels, it is quite a logical next step to add this
support to the kernel build.
create bootloader-specific files doesn't seem like a good idea. Doing so
would require pulling in even more outside tools into the kernel build flow.
As for pulling additional tools, dtc is already a part of the kernel
so the idea is to use existing tools.
All you need is to copy the zImage and any relevant .dtb files into
/boot, and have U-Boot load the relevant .dtb file by constructing the
filename as roughly ${soc}-${board}.dtb, then use the bootz command to
boot it. You can have a completely generic boot.scr (or built-in script).
FIT doesnt need any such bootloader variables and thus benefits from
the simplicity.
Note: Not all (many?) U-Boot support FIT anyway, so you'd need to flash
For these boards, we can special case to doing a non-fit boot to keep
them backward-compatibility. I don't think maintaining
backward-compatibility requires any additional work, but just building
the kernel with a different make target.
Regards,
Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
