From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 19 Feb 2014 12:16:13 -0700 Subject: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work. In-Reply-To: <20140219191027.GZ19081@bill-the-cat> References: <1392659798-1665-1-git-send-email-dennis@ausil.us> <1392659798-1665-2-git-send-email-dennis@ausil.us> <5304FB87.3020208@ti.com> <5304FC99.8070009@wwwdotorg.org> <5304FD57.3040508@ti.com> <5304FE7E.2060805@wwwdotorg.org> <5304FEF9.1030104@ti.com> <5305002C.8050905@wwwdotorg.org> <20140219191027.GZ19081@bill-the-cat> Message-ID: <530502FD.5080607@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/19/2014 12:10 PM, Tom Rini wrote: ... >> A generic Linux distro wouldn't be installing a kernel to NAND, but >> would rather put it into the /boot filesystem. NAND boot is something >> that'd be best supported by the custom hook we discussed above. > > Wait, why would a generic Linux distro be installing to eMMC but not to > NAND ? Not that this series needs to be the final point in the > discussion and all. I should point out that I was talking about raw NAND MTD partitions rather than a NAND device with a regular partition table and normal filesystems within it. If the NAND is exposed as a regular block device with a regular filesystem, then it'd look just like any other block device to a generic distro installer, and hence it could put /boot there, and this patch (or future enhancement) could certainly usefully contain a generic bootcmd_nand that used it. However, if the NAND has hard-coded MTD partitions, and/or the partitions have no filesystem but rather contain e.g. a raw zImage/uImage, then that would require board-/SoC-specific support in the distro kernel and installer, and hence we wouldn't be talking about a *generic* installer/distro, and *generic* installers/distros are what this patch series is all about. >> The commit description for this commit should have set the scene that >> this series is all about providing a way for a generic Linux distro to >> create a generic installable media set that boots the same way across n >> different boards with U-Boot, and similarly also to set up the installed >> distro filesystem in a single generic way that can boot on any board it >> gets installed to. It's all about avoiding board-specific boot options >> such as NAND, and hence may well not be applicable to boards that >> primarily/only boot from NAND; they would still need custom distro >> install media and hooks to set up the installed filesystem. > > Why is NAND special but SATA not, other than desktops often have SATA > exposed but not NAND? Even more so when you consider that from the > Linux side of things, dealing with NAND is dealing with NAND and it's > not board specific.