From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.
Date: Wed, 19 Feb 2014 12:16:13 -0700 [thread overview]
Message-ID: <530502FD.5080607@wwwdotorg.org> (raw)
In-Reply-To: <20140219191027.GZ19081@bill-the-cat>
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.
next prev parent reply other threads:[~2014-02-19 19:16 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 17:56 [U-Boot] RFC unified boot environment Dennis Gilmore
2014-02-17 17:56 ` [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work Dennis Gilmore
2014-02-19 13:42 ` Tom Rini
2014-02-19 13:57 ` Dennis Gilmore
2014-02-19 15:54 ` Marek Vasut
2014-02-19 17:28 ` Stephen Warren
2014-02-19 17:30 ` Marek Vasut
2014-02-19 17:41 ` Stephen Warren
2014-02-19 17:44 ` Marek Vasut
2014-02-19 17:40 ` Stephen Warren
2014-02-22 8:20 ` Dennis Gilmore
2014-02-24 18:40 ` Stephen Warren
2014-02-24 20:07 ` Tom Rini
2014-02-19 18:44 ` Dan Murphy
2014-02-19 18:48 ` Stephen Warren
2014-02-19 18:52 ` Dan Murphy
2014-02-19 18:57 ` Stephen Warren
2014-02-19 18:59 ` Dan Murphy
2014-02-19 19:04 ` Stephen Warren
2014-02-19 19:10 ` Tom Rini
2014-02-19 19:16 ` Stephen Warren [this message]
2014-02-19 19:36 ` Tom Rini
2014-02-19 19:43 ` Stephen Warren
2014-02-19 19:57 ` Tom Rini
2014-02-19 20:10 ` Dennis Gilmore
2014-02-19 19:32 ` Dan Murphy
2014-02-19 19:38 ` Stephen Warren
2014-02-19 20:03 ` Dan Murphy
2014-02-19 19:02 ` Eric Nelson
2014-02-19 19:05 ` Dan Murphy
2014-02-19 19:16 ` Tom Rini
2014-02-19 19:24 ` Dan Murphy
2014-02-19 19:29 ` Stephen Warren
2014-02-19 19:37 ` Dan Murphy
2014-02-19 19:43 ` Tom Rini
2014-02-19 19:41 ` Tom Rini
2014-02-19 21:20 ` Denys Dmytriyenko
2014-02-20 12:31 ` Otavio Salvador
2014-02-20 13:46 ` Tom Rini
2014-02-22 12:56 ` Otavio Salvador
2014-02-17 17:56 ` [U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs Dennis Gilmore
2014-02-19 13:52 ` Tom Rini
2014-02-19 17:46 ` Stephen Warren
2014-02-19 19:57 ` Dan Murphy
2014-02-19 19:58 ` Dan Murphy
2014-02-19 20:05 ` Stephen Warren
2014-02-19 20:20 ` Dan Murphy
2014-02-19 20:22 ` Stephen Warren
2014-02-19 20:31 ` Dan Murphy
2014-02-19 20:38 ` Stephen Warren
2014-02-19 20:58 ` Dan Murphy
2014-02-19 21:07 ` Dennis Gilmore
2014-02-17 17:56 ` [U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment Dennis Gilmore
2014-02-19 11:52 ` Otavio Salvador
2014-02-19 17:50 ` Stephen Warren
2014-02-18 10:18 ` [U-Boot] RFC unified boot environment Stefano Babic
2014-02-18 16:09 ` Dennis Gilmore
2014-02-19 13:33 ` Tom Rini
2014-03-20 22:12 ` [U-Boot] [PATCH 0/6] " Dennis Gilmore
2014-03-20 22:12 ` [U-Boot] [PATCH 1/6] add README.distro file Dennis Gilmore
2014-03-21 18:48 ` Tom Rini
2014-03-25 20:40 ` Stephen Warren
2014-03-25 20:24 ` Stephen Warren
2014-03-28 15:42 ` Tom Rini
2014-03-28 16:11 ` Stephen Warren
2014-03-28 16:25 ` Tom Rini
2014-03-20 22:12 ` [U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined Dennis Gilmore
2014-03-21 18:37 ` Marek Vasut
2014-03-21 18:53 ` Tom Rini
2014-03-21 21:00 ` Marek Vasut
2014-03-21 18:48 ` Tom Rini
2014-03-25 20:38 ` Stephen Warren
2014-03-25 20:36 ` Stephen Warren
2014-03-20 22:12 ` [U-Boot] [PATCH 3/6] move wandboard over to use the generic distro configuation and environment Dennis Gilmore
2014-03-20 22:12 ` [U-Boot] [PATCH 4/6] move beagleboard " Dennis Gilmore
2014-03-21 18:48 ` Tom Rini
2014-03-20 22:13 ` [U-Boot] [PATCH 5/6] move pandaboard " Dennis Gilmore
2014-03-21 18:49 ` Tom Rini
2014-03-20 22:13 ` [U-Boot] [PATCH 6/6] pxe: additionaly check for fdt_file env variable Dennis Gilmore
2014-03-21 18:49 ` Tom Rini
2014-03-25 20:45 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530502FD.5080607@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.