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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen, In message 51475997.2060...@wwwdotorg.org you wrote: Raw zImage /is/ the useful format that should be adopted. This one size fits all approch does fit everywhere. There are a number of users (including _big_ commercial ones, with _large_ numebrs of systems in the field) that have simple requirements like: - how can I find out if the image I just loaded to RAM in OK (OK maning some checksum is correct, or some crypto-key could be verified, or ...) ? - how can I find out which version of image is installed on this device in the flash? Can I print something like an ID string, or a build timestamp, etc? etc. etc. zImage may work well in many cases, but there are also many cases where in image format that allows for additional meta-data is mandatory. 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 Minds are like parachutes - they only function when open. -- 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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build tools at all.
If the world was so simple, we could eventually do that. But it ain't
so. Just consider the typical diskless system that boots over the
network, using DHCP + TFTP, where the server will provide a single
file only. Or systems that require sub-second boot times, where you
don't want to spend time in running boot scripts. etc.
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
We see things not as they are, but as we are. - H. M. Tomlinson
--
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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen, In message 51267e0a.3060...@wwwdotorg.org you wrote: so. Just consider the typical diskless system that boots over the network, using DHCP + TFTP, where the server will provide a single file only. I use TFTP routinely to boot my boards, and load separate zImage and DTB files from the server without issue, using the exact same filenames as when I load them from a /boot directory on eMMC or SD. You may do this in a development environment; I do the same routinely here. But there are users out there who commission large installations like that; they simply do not want to have multiple files for each system (and not even for each configuration). And besides, there's always some script, whether it's a boot.scr file or built into the U-Boot environment. Not really - especially not when booting using Falcon mode. 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 If you can't beat it or corrupt it, you pretend it was your idea in the first place. - Terry Pratchett, _Guards! Guards!_ -- 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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Nicolas, In message alpine.lfd.2.03.1302211624561.6...@syhkavp.arg you wrote: No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that Actually this is neither the only, nor even the primary purpose of FIT images; these have a much wider scope of usage scenarios. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. 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 GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 371140df@csnews -- 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: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Jason, In message 20130221232821.ga2...@obsidianresearch.com you wrote: own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. Agreed.. We do that here as well, the DT is also used to describe the functionality inside FPGA(s). We do things like declare a GPIO controller inside the FPGA, then stack the bitbang MDIO/I2C on top of that, then declare a bunch of devices on those busses. DT makes this extremely straightforward. However, it is critical that the DT, kernel and FPGA are matched together - we always arrange things so that the DTB, kernel and FPGA config are bundled together and update atomically during firmware upgrade. Agreed. Xilinx's Zynq is a great example of this kind of stuff, FWIW. IIRC Indeed - Xilinx's Zynq, Altera's SoC FPGA, and others. Such highly flexible hardware configurations require a new level of software support that by far exceeds the classic static setups of more PC-like systems where the only change you would expect is adding or removing some PCI cards or the like. 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 Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling -- 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
