sunxi: Fix boot of Cubietruk and al.
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
Quoted 55 lines · Karsten Merker
[CCing Vagrant Cascadian, the Debian U-Boot maintainer]
Quoted 8 lines · Andre Przywara
Quoted 7 lines · Siarhei Siamashka
Quoted 5 lines · On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <[email protected]>…
That being said I have prepared a patch to switch sunxi ARM64 boards
over toENV_IS_IN_FAT, because I guess we will hit the wall soon there
and have no Thumb2 to get off lightly.[...]
Quoted 12 lines
Quoted 12 lines
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.txtQuoted 8 lines
Quoted 8 lines
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_targetsvariable 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.
Quoted 3 lines
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.
Quoted 12 lines
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.
Quoted 25 lines
Quoted 7 lines
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.Quoted 5 lines
Quoted 3 lines
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 :-).
Quoted 2 lines
Quoted 2 lines
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.
Quoted 2 lines
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