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