[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El mié, 25-10-2017 a las 20:41 +0200, Karsten Merker escribió:
> [CCing Vagrant Cascadian, the Debian U-Boot maintainer]
> 
> On Wed, Oct 25, 2017 at 02:42:50PM +0100, Andre Przywara wrote:
> > On 25/10/17 12:58, Siarhei Siamashka wrote:
> > > On Tue, 24 Oct 2017 18:21:43 +0100
> > > Andre Przywara <andre.przywara at arm.com> wrote:
> > > > That being said I have prepared a patch to switch sunxi ARM64
> > > > boards
> > > > over to ENV_IS_IN_FAT, because I guess we will hit the wall
> > > > soon there
> > > > and have no Thumb2 to get off lightly.
> 
> [...]
> > > I don't think that we have any significant number of U-Boot env
> > > users
> > > on 32-bit sunxi hardware either. For example, we can do a search
> > > in
> > > the linux-sunxi wiki to compare the usage of environment vs.
> > > boot.scr
> > > and uEnv.txt:
> > > 
> > >    https://linux-sunxi.org/index.php?search=saveenv
> > >    https://linux-sunxi.org/index.php?search=boot.scr
> > >    https://linux-sunxi.org/index.php?search=uenv.txt
> > > 
> > > Using saveenv is justified only in very rare exceptional cases.
> > > They do
> > > exist, otherwise Maxime would not have encountered the problem in
> > > the
> > > first place. But I think that we should encourage Maxime to
> > > migrate 
> > > away from it. I would really like to know a bit more about his
> > > use case.
> 
> Hello,
> 
> I cannot speak for Maxime, but from a distro point of view there are
> at
> least two common usecases:
> 
> a) Changing the default boot order
> 
>    At least among Debian users it is not uncommon to run the
>    installer from an SD-card (Debian provides SD-card images with
>    u-boot and the Debian installer) and install the distro to a
>    harddisk (especially on the A20 where native SATA is
>    available).  The default boot order is MMC before SATA and
>    USB, i.e. after installing to SATA or USB, the user must
>    change the boot order by setting the boot_targets variable
>    accordingly and saving it into the persistent environment,
>    because otherwise the system would reboot into the installer
>    on the SD card all the time instead of booting the installed
>    system.  Removing the SD card isn't an option because then
>    there wouldn't be any (mainline) u-boot anymore.
> 
>    This isn't a problem when installing to the SD-card from which
>    the installer was loaded as the SD-card gets repartitioned and
>    the installer is overwritten in that case.
This is a bit unfortunate, if only we had spi or some other flash for
stroing u-boot on all the hardware so that vendors could ship something
that just works. wiping out the installer would b an option, but that
is pretty ugly. 

> b) Changing the default console device
> 
>    The Debian boot.scr passes the contents of the u-boot console
>    variable to the kernel as the system console device.  All
>    sunxi-based systems default to serial console, but there are
>    quite a number of users that don't have a serial console cable
>    but instead run their console on HDMI.  They change their
>    system console by setting the u-boot "console" variable
>    accordingly and running saveenv. This works as u-boot runs
>    its own console both on serial and simplefb in parallel, while
>    the Linux kernel can only have one system console device at
>    a time.
u-boot and the linux kernel actually default to displaying to both the
serial console and the HDMI console. the user can intereact with both
at the same time. At least it is true on the sunxi machines I have
tested it on, with zero need to setup any console lines or do anything
special. I suspect that you no longer need to have a boot.scr at all.

> > As mentioned above, I don't care so much about a saved environment,
> > but
> > I am merely a "user" of U-Boot, so it's not really my call.
> > As long as there is a non-negligible amount of users, we should
> > consider
> > preserving the saved environment.
> > 
> > > The Linux distributions don't seem to rely on the U-Boot
> > > environment
> > > (if I understood their feedback correctly).
> > 
> > That would be an interesting data point to know for sure.
> 
> Please see above :-).
> 
> > > Currently boot.scr or uEnv.txt is loaded from FAT or other
> > > partitions as part of distro boot. Is this really not enough?

> In Debian's case it is "other partitions". Debian doesn't create
> any FAT partitions on non-UEFI systems. The /boot partition is
> ext2 and for the other partitions ext4 is the default filesystem.
> Therefore forcing the environment onto a FAT partition would
> surely cause problems when upgrading an existing system to a
> newer u-boot version.
> 
> uEnv.txt is AFAICS not used by mainline u-boot at all, at least
> on sunxi-based systems.

Fedora does not use or support uEnv.txt or boot.scr our disk images
ship with a fat partition at the start so that we can ship the firmware
needed to boot on a raspberry pi, however any 32 bit system installed
using anaconda will not have a fat partition at all. /boot is ext4 and
depeding on if you use server or a different installer you will by
default get xfs or ext4 on lvm, there is the ability to choose
different options. Older disk images before we supported raspberry pi
did not have fat partition at all. so there is likely a lot of machines
without access to afat partition that would break if if it became
required.

Dennis