-----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