Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Montag, den 16.01.2017, 21:41 +0100 schrieb Karsten Merker: > On Mon, Jan 16, 2017 at 08:07:50PM +0100, permondes - sagen wrote: > > Am Montag, den 16.01.2017, 00:14 +0100 schrieb Karsten Merker: > > > > Could you (after making an image backup of your SD card so that > > > you can easily restore the previous setup) please try the > > > following procedure on the LIME: > > > > > > $ sudo apt-get install u-boot-sunxi > > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > > > of=/dev/mmcblk0 bs=1k seek=8 > > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > > $ sudo flash-kernel > > > $ sync > > > $ sudo reboot > > > > > > This should (at least in theory) provide you with a booting > > > system, unless there is some freedombox-specific mechanism > > > that modifies the boot.scr behind flash-kernel's back. > > > > > > Regards, > > > Karsten > > > > Hi Karsten, > > I followed your instructions to the letter: > > > > > $ sudo apt-get install u-boot-sunxi > > > u-boot-sunxi ist schon die neueste Version (2016.11+dfsg1-3). > > > 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht > > > aktualisiert. > > > > > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > > > of=/dev/mmcblk0 bs=1k seek=8 > > > 471+1 Datensätze ein > > > 471+1 Datensätze aus > > > 482846 Bytes (483 kB, 472 KiB) kopiert, 0,0468861 s, 10,3 MB/s > > > > > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > > 128+0 Datensätze ein > > > 128+0 Datensätze aus > > > 131072 Bytes (131 kB, 128 KiB) kopiert, 0,0190237 s, 6,9 MB/s > > > > > > $ sudo flash-kernel > > > DTB: sun7i-a20-olinuxino-lime.dtb > > > Installing > > > /usr/lib/linux-image-4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb into > > > /boot/dtbs/4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb > > > Taking backup of sun7i-a20-olinuxino-lime.dtb. > > > Installing new sun7i-a20-olinuxino-lime.dtb. > > > flash-kernel: installing version 4.8.0-2-armmp-lpae > > > Generating boot script u-boot image... done. > > > Taking backup of boot.scr. > > > Installing new boot.scr. > > > > > > $ sync > > > > > > $ sudo reboot > > > Connection to ... closed by remote host. > > > Connection to ... closed. > > > > As I could not ssh into it even after 5 minutes (usually it > > booted in 1-2 mins.), I tried with > > > > > nmap -p 80 --open -sV /24 > > > > but the device was not shown. Also the router web interface did > > not show it. > > That is indeed strange. I am sorry to have to say that we > probably won't be able to debug this any further without access > to the boot console. Flash-kernel and the boot script created by > it work without problems on my A20-based systems which were > installed with debian-installer, so it appears that the issue is > probably something specific to the freedombox setup. It might > have something to do with the way the SD card is partitioned or > with the use of btrfs as the root filesystem and the additional > kernel parameters that the freedombox-bootscript provides, but > without a boot log the exact issue is very difficult to > determine. > > > We can give up any time. I have a work around for the moment > > and can ask the Freedombox people to generate a new image with > > the current u-boot environment. > > Shall we keep the bug against flash-kernel open or shall we close > it? If the former, I would tag it "moreinfo" as we effectively > cannot solve the issue without further information about what > exactly happens during the boot process on your system. > > Regards, > Karsten Please close the bug. I will try to get a fw_env.config or set up a new system. The issue is probably Freedombox related and working on it does not advance this project. Thanks a lot for your support. Dietmar
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Mon, 2017-01-16 at 20:11 +0100, permondes - sagen wrote: > no luck: > > > $ fw_printenv > > Cannot parse config file '/etc/fw_env.config': No such file or > > directory > > and indeed, the file does not exist. Yes, you would need to obtain or produce one suitable for your device, it's not automatically installed. There are various examples in /usr/share/doc/u-boot-tools/examples/ but you would likely need to find an one for your device with a search engine or produce one based on knowing where your u-boot saves the env. Ian.
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Montag, den 16.01.2017, 14:12 + schrieb Ian Campbell: > On Mon, 2017-01-16 at 00:14 +0100, Karsten Merker wrote: > > On Sun, Jan 15, 2017 at 08:24:37PM +0100, permondes - sagen wrote: > > > Copying back the previous boot.scr made it boot again. The environment > > > variables were the same as before. So I am back where I have been > > > before. > > > > To make sure that we are talking about the same thing here: You > > wrote before that you have no way to access the u-boot prompt, so > > how do you know what your current u-boot environment looks like? > > FWIW fw_printenv from the u-boot-tools package can read the u-boot env, > given an appropriate config in /etc/fw_env.config. > > There is also fw_setenv to to set them, don't think it supports setting > to defaults or anything like that though. > > Ian. Hi Ian, no luck: > $ fw_printenv > Cannot parse config file '/etc/fw_env.config': No such file or directory and indeed, the file does not exist. Dietmar
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Montag, den 16.01.2017, 00:14 +0100 schrieb Karsten Merker: > On Sun, Jan 15, 2017 at 08:24:37PM +0100, permondes - sagen wrote: > > Am Sonntag, den 15.01.2017, 12:39 +0100 schrieb Karsten Merker: > > > On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > [...] > > To make sure that we are talking about the same thing here: You > wrote before that you have no way to access the u-boot prompt, so > how do you know what your current u-boot environment looks like? > Is it perhaps possible that you mix up the u-boot environment and > the Linux shell environment? The boot.scr is not executed by a > Linux shell; u-boot has its own internal bourne-shell-style > scripting language and has its own shell environment, which is > completely separate from any Linux shell environment. You are right, I have been talking about the Linux shell not the u-boot environment. Sorry, my mistake. > > > My understanding is, that this strange behavior is due to a transition > > that happened in the Freedombox project. So I will ask them to provide > > updated live images to start with a fresh and correct system instead of > > wasting time and trying to solve this particular case. > > Could you (after making an image backup of your SD card so that > you can easily restore the previous setup) please try the > following procedure on the LIME: > > $ sudo apt-get install u-boot-sunxi > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > of=/dev/mmcblk0 bs=1k seek=8 > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > $ sudo flash-kernel > $ sync > $ sudo reboot > > This should (at least in theory) provide you with a booting > system, unless there is some freedombox-specific mechanism > that modifies the boot.scr behind flash-kernel's back. > > Regards, > Karsten Hi Karsten, I followed your instructions to the letter: > $ sudo apt-get install u-boot-sunxi > u-boot-sunxi ist schon die neueste Version (2016.11+dfsg1-3). > 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > of=/dev/mmcblk0 bs=1k seek=8 > 471+1 Datensätze ein > 471+1 Datensätze aus > 482846 Bytes (483 kB, 472 KiB) kopiert, 0,0468861 s, 10,3 MB/s > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > 128+0 Datensätze ein > 128+0 Datensätze aus > 131072 Bytes (131 kB, 128 KiB) kopiert, 0,0190237 s, 6,9 MB/s > > $ sudo flash-kernel > DTB: sun7i-a20-olinuxino-lime.dtb > Installing > /usr/lib/linux-image-4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb into > /boot/dtbs/4.8.0-2-armmp-lpae/sun7i-a20-olinuxino-lime.dtb > Taking backup of sun7i-a20-olinuxino-lime.dtb. > Installing new sun7i-a20-olinuxino-lime.dtb. > flash-kernel: installing version 4.8.0-2-armmp-lpae > Generating boot script u-boot image... done. > Taking backup of boot.scr. > Installing new boot.scr. > > $ sync > > $ sudo reboot > Connection to ... closed by remote host. > Connection to ... closed. As I could not ssh into it even after 5 minutes (usually it booted in 1-2 mins.), I tried with > nmap -p 80 --open -sV /24 but the device was not shown. Also the router web interface did not show it. I reverted to the old (Freedombox) boot.scr and it re-appeared. We can give up any time. I have a work around for the moment and can ask the Freedombox people to generate a new image with the current u-boot environment. Thanks, Dietmar
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Mon, 2017-01-16 at 00:14 +0100, Karsten Merker wrote: > On Sun, Jan 15, 2017 at 08:24:37PM +0100, permondes - sagen wrote: > > Copying back the previous boot.scr made it boot again. The environment > > variables were the same as before. So I am back where I have been > > before. > > To make sure that we are talking about the same thing here: You > wrote before that you have no way to access the u-boot prompt, so > how do you know what your current u-boot environment looks like? FWIW fw_printenv from the u-boot-tools package can read the u-boot env, given an appropriate config in /etc/fw_env.config. There is also fw_setenv to to set them, don't think it supports setting to defaults or anything like that though. Ian.
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
Am Sonntag, den 15.01.2017, 12:39 +0100 schrieb Karsten Merker: > On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > > > > 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. > > Not necessarily. The boot.scr is generated by the flash-kernel > package on every kernel update, but the u-boot in the boot area is > not automatically updated with an update of the u-boot-sunxi > package, so unless the people who have built the freedombox upgrade > mechanism have explicitly implemented a function to update the > u-boot in the boot area (which I doubt), you will probably still > have whatever older u-boot version was used when building the > original freedombox image. > > > 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. > > Hm, that poses a problem. The "normal" way is via serial console, > or, if the u-boot version is relatively new, via a display > connected to the HDMI port and a USB keyboard. U-Boot isn't memory > resident (except for the PSCI functions), i.e. once the Linux > kernel is booted, there is no u-boot anymore with which one could > interact directly. > > What you could try is clobbering the area on the SD card in which > u-boot stores the environment. This results in a checksum mismatch > and u-boot falls back to the integrated default environment. On > the LIME, the u-boot environment is stored on the SD card starting > at offset 544kB from the start of the device, and is 128kB in size. > So on the LIME running > > $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 > > should overwrite the complete environment area with zeros, > resulting in u-boot falling back to the built-in defaults. But > without some form of console you still won't be able to see which > version of u-boot is really installed (cf. my mail to debian-arm) > and what exactly happens at boot time. If you want to make sure > that you have a current u-boot version installed, you can replace > whatever version is currently on the SD card by running > > $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin > of=/dev/mmcblk0 bs=1k seek=8 > > Doing all this "blind" without console is of course inherently > dangerous, so make an image backup of your SD card that you can > restore in case of problems before trying any of this. > > HTH, > Karsten Hi Karsten, this what I did: to get a fresh boot.scr I used a command I got from the freedombox list some time ago: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Then I zeroed the environment and copied the correct u-boot. The devices booted, but I realized that boot.scr did not have the correct content, so I copied the before mentioned boot script for Allwinner SunXi-based devices over it and restarted the device. This time, it did not boot afterwards. Copying back the previous boot.scr made it boot again. The environment variables were the same as before. So I am back where I have been before. My understanding is, that this strange behavior is due to a transition that happened in the Freedombox project. So I will ask them to provide updated live images to start with a fresh and correct system instead of wasting time and trying to solve this particular case. Thanks for your support anyway Dietmar
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > > 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. Not necessarily. The boot.scr is generated by the flash-kernel package on every kernel update, but the u-boot in the boot area is not automatically updated with an update of the u-boot-sunxi package, so unless the people who have built the freedombox upgrade mechanism have explicitly implemented a function to update the u-boot in the boot area (which I doubt), you will probably still have whatever older u-boot version was used when building the original freedombox image. > 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. Hm, that poses a problem. The "normal" way is via serial console, or, if the u-boot version is relatively new, via a display connected to the HDMI port and a USB keyboard. U-Boot isn't memory resident (except for the PSCI functions), i.e. once the Linux kernel is booted, there is no u-boot anymore with which one could interact directly. What you could try is clobbering the area on the SD card in which u-boot stores the environment. This results in a checksum mismatch and u-boot falls back to the integrated default environment. On the LIME, the u-boot environment is stored on the SD card starting at offset 544kB from the start of the device, and is 128kB in size. So on the LIME running $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 should overwrite the complete environment area with zeros, resulting in u-boot falling back to the built-in defaults. But without some form of console you still won't be able to see which version of u-boot is really installed (cf. my mail to debian-arm) and what exactly happens at boot time. If you want to make sure that you have a current u-boot version installed, you can replace whatever version is currently on the SD card by running $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1k seek=8 Doing all this "blind" without console is of course inherently dangerous, so make an image backup of your SD card that you can restore in case of problems before trying any of this. 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.
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 0x4600
> > setenv initrd_addr 0x4800
> > setenv fdtaddr 0x4700
> >
> > setenv initrd_high 0x
> > setenv fdt_high 0x
> >
> > 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 0x4430 to allow for initrds larger than
> > # 13MB on u-boot-sunxi.
> > setenv kernel_addr_r 0x4200
> > setenv fdt_addr_r 0x4300
> > setenv ramdisk_addr_r 0x4430
> > 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
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 0x4600
> setenv initrd_addr 0x4800
> setenv fdtaddr 0x4700
>
> setenv initrd_high 0x
> setenv fdt_high 0x
>
> 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 0x4430 to allow for initrds larger than
> # 13MB on u-boot-sunxi.
> setenv kernel_addr_r 0x4200
> setenv fdt_addr_r 0x4300
> setenv ramdisk_addr_r 0x4430
> 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.
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
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 0x4600
setenv initrd_addr 0x4800
setenv fdtaddr 0x4700
setenv initrd_high 0x
setenv fdt_high 0x
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
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 0x4430 to allow for initrds larger than
# 13MB on u-boot-sunxi.
setenv kernel_addr_r 0x4200
setenv fdt_addr_r 0x4300
setenv ramdisk_addr_r 0x4430
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.
As work-around I am currently copying a saved version of the former file
content to boot.scr.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 4.8.0-2-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages flash-kernel depends on:
ii debconf [debconf-2.0] 1.5.59
ii devio 1.2-1.2
ii initramfs-tools0.126
ii linux-base 4.5
ii mtd-utils 1:2.0.0-1
ii ucf3.0036
Versions of packages flash-kernel recommends:
ii u-boot-tools 2016.11+dfsg1-3
flash-kernel suggests no packages.
-- debconf information:
flash-kernel/linux_cmdline: quiet
Dietmar
