Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker:
> 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
The device is being used as a FreedomBox, a flavour of Debian. They
provide an initial "live" image which is quite old actually. Updating to
the current version, which is done automatically during set-up, makes
this change of boot.scr, so I guess they switched to standard u-boot.
I would like to test the reset of the environment, how do I get into
u-boot prompt? I just have ssh access to the box, no serial, nor
keyboard or so.
Dietmar
Reply to: