[U-Boot] [PATCH] rockchip: set scan_dev_for_boot_part env for rockchip SoC

[Sjoerd Simons]

On Wed, 2017-03-08 at 22:38 +0800, Eddie Cai wrote:
> 2017-03-08 17:29 GMT+08:00 Sjoerd Simons <sjoerd.simons at collabora.co.
> uk>:
> 
> > On Wed, 2017-03-08 at 09:30 +0800, Eddie Cai wrote:
> > > Hi Simon
> > > 
> > > 2017-03-06 14:46 GMT+08:00 Eddie Cai <eddie.cai.linux at gmail.com>:
> > > 
> > > > Hi Simon
> > > > 
> > > > 2017-02-23 11:33 GMT+08:00 Simon Glass <sjg at chromium.org>:
> > > > 
> > > > > Hi Eddie,
> > > > > 
> > > > > On 22 February 2017 at 07:12, Eddie Cai <eddie.cai.linux at gmai
> > > > > l.co
> > > > > 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.
> > 
> 
> We define PARTS_DEFAULT in rockchip-common.h. All rockchip SoC based
> board
> include this file.
> #define PARTS_DEFAULT \
> "uuid_disk=${uuid_gpt_disk};" \
> "name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};" \
> "name=reserved1,size=64K,uuid=${uuid_gpt_reserved1};" \
> "name=reserved2,size=4M,uuid=${uuid_gpt_reserved2};" \
> "name=loader2,size=4MB,uuid=${uuid_gpt_loader2};" \
> "name=atf,size=4M,uuid=${uuid_gpt_atf};" \
> "name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};" \
> "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \

Yeah, that's not the partition everyone *must* use for rockchip though.
Definately not the one distributions (or I myself use for our rockchip
images) on their installations. This is somewhat specific to a
deployment not generic :)

> > 
> > 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.
> > 
> 
> That is correct. Also that is why i want to limit the change on
> Rockchip
> SoC based board.
> 
> > 
> > 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
> > :)
> > 
> 
> Yes, I should limit it on the first boot device.

Why do it at all? Especially automatically on boot?

I can see the point for forcing a given GPT partition table if using u-
boot to flash the emmc (via dfu or whatever), for which PARTS_DEFAULT
makes total sense. 

But in all other cases, u-boot should really not force policy here
necessarily and especially not do destructive changes without the user
requisting/triggering it specifically.

-- 
Sjoerd Simons
Collabora Ltd.