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
