-----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 list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
