[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot



On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote:

> Package: flash-kernel
> Version: 3.73
> Severity: important
> 
> Dear Maintainer,
> 
> I am using an OLinuXino A20 LIME with arm. 
> boot.scr used to have the following content (I removed the initial
> non-readable characters) which let boot the device without issues:
> 
> setenv mmcpart 1
> 
> setenv mmcroot /dev/mmcblk0p2 ro
> setenv mmcrootfstype btrfs rootwait fixrtc
> setenv mmcrootflags subvol=@
> 
> setenv console ttyS0,115200n8
> 
> setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
> setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
> setenv fdtfile sun7i-a20-olinuxino-lime.dtb
> 
> setenv loadaddr 0x46000000
> setenv initrd_addr 0x48000000
> setenv fdtaddr 0x47000000
> 
> setenv initrd_high 0xffffffff
> setenv fdt_high 0xffffffff
> 
> setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${kernel_file}
> setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
> ${initrd_file}\; setenv initrd_size \${filesize}
> setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
> 
> setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
> setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
> rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}
> 
> run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
> ${initrd_size} ${fdtaddr}
> 
> <-- end of file

To my knowledge Debian has never provided a boot script with this
content as a part of its official flash-kernel releases.  Is this
perhaps from some non-official Debian image that somebody else
has produced, e.g. from some image provided by the hardware
manufacturer or from some other project that uses Debian as its
base but doesn't use Debian's normal mechanisms for handling the
boot scripts?

Which u-boot version do you have installed? Can you provide the
output of the "printenv" command at the u-boot prompt?

> The new content of that file is:
> 
> # boot script for Allwinner SunXi-based devices
> 
> # Mainline u-boot v2014.10 introduces a new default environment and
> # a new common bootcmd handling for all platforms, which is not fully
> # compatible with the old-style environment used by u-boot-sunxi.
> # This script therefore needs to check in which environment it
> # is running and set some variables accordingly.
> 
> # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> # are set.
> 
> # The new-style environment predefines ${boot_targets}, the old-style
> # environment does not.
> if test -n "${boot_targets}"
> then
>   echo "Mainline u-boot / new-style environment detected."
>   # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
>   # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
>   # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
>   if test -z "${device}"; then setenv device "${devtype}"; fi
>   if test -z "${partition}${distro_bootpart}"; then setenv partition
> "${devnum}:${bootpart}"; fi
>   if test -z "${partition}"; then setenv partition "${devnum}:
> ${distro_bootpart}"; fi
> else
>   echo "U-boot-sunxi / old-style environment detected."
>   # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
>   # ramdisk_addr_r, so they have to be manually set. Use the values
>   # from mainline u-boot v2014.10, except for ramdisk_addr_r,
>   # which is set to 0x44300000 to allow for initrds larger than
>   # 13MB on u-boot-sunxi.
>   setenv kernel_addr_r 0x42000000
>   setenv fdt_addr_r 0x43000000
>   setenv ramdisk_addr_r 0x44300000
> fi
> 
> if test -n "${console}"; then
>   setenv bootargs "${bootargs} console=${console}"
> fi
> 
> setenv bootargs  ${bootargs} quiet
> 
> 
> image_locations='/boot/ /'
> if test -z "${fk_kvers}"; then
>    setenv fk_kvers '4.8.0-2-armmp-lpae'
> fi
> 
> if test -n "${fdtfile}"; then
>    setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
>    setenv fdtpath dtb-${fk_kvers}
> fi
> 
> for pathprefix in ${image_locations}
> do
>   if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
>   then
>     load ${device} ${partition} ${kernel_addr_r}
> ${pathprefix}vmlinuz-${fk_kvers} \
>     && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
> \
>     && load ${device} ${partition} ${ramdisk_addr_r}
> ${pathprefix}initrd.img-${fk_kvers} \
>     && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
> \
>     && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
>   fi
> done
> 
> <- end of file
> 
> Which does not allow the device to boot. 
> None of the variables in that script is set in the current environment.

This points at a problem with either your u-boot version or your
u-boot environment.  The oldest u-boot version that Debian has
ever shipped for the Olinuxino A20 LIME as part of the official
Debian-Installer images has been mainline u-boot v2014.10, and
all mainline u-boot versions since v2014.10 provide a default
environment that is compatible with this boot script.

Please note that u-boot keeps its old environment on upgrade by
default, i.e. if you originally had e.g. some vendor-specific
u-boot installed and upgraded to mainline u-boot later, this
would have kept the environment from the vendor u-boot. You can
reset the u-boot environment to its current default by running
"env default -a; saveenv" at the u-boot command prompt.

HTH,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


Reply to: