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.
Reply to: