From: Sjoerd Simons Date: Wed, 08 Mar 2017 10:29:28 +0100 Subject: [U-Boot] [PATCH] rockchip: set scan_dev_for_boot_part env for rockchip SoC In-Reply-To: References: <1487318222-1282-1-git-send-email-eddie.cai.linux@gmail.com> Message-ID: <1488965368.3119.5.camel@collabora.co.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, 2017-03-08 at 09:30 +0800, Eddie Cai wrote: > Hi Simon > > 2017-03-06 14:46 GMT+08:00 Eddie Cai : > > > Hi Simon > > > > 2017-02-23 11:33 GMT+08:00 Simon Glass : > > > > > Hi Eddie, > > > > > > On 22 February 2017 at 07:12, Eddie Cai > > m> > > > wrote: > > > > Hi Simon > > > > > Look like Tom don't like put this changes to default environment. See > [0]. > I think I would have to limit this change on Rockchip SoC because i > can > only guarantee GPT table exist on Rockchip SoC. What do you think? > [0]: https://patchwork.ozlabs.org/patch/735557/ How can you guarantee that it exists on all rockchip deployments? This very much depends on the software stack/image people use on rockchip boards. One of the nice things about the distro bootcmds is that it's a flexible generic setup which should just work regardless of how systems are installed (as long as some basic conventions are followed). There isn't really a requirement for people to use GPT on those system. Also from a quick look, this seems to want to automatically write GPT tables on whatever boot device is scanned, not just the internal media. So you're adding a big potential for destroying peoples SD cards here :) Fwiw I'm also not sure what actual value of writing a GPT table is? It's extremely unlikely that this would then allow you to successfully boot from the device afterwards. -- Sjoerd Simons Collabora Ltd.