Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote:
> Control: tags -1 +patch
>
> On 2015-04-14, Karsten Merker wrote:
> > On Tue, Apr 14, 2015 at 03:51:45PM +0200, François-Régis wrote:
> >> Le 14/04/2015 14:05, Ben Hutchings a écrit :
> >> > On Tue, 2015-04-14 at 13:24 +0200, Francois-Regis Vuillemin wrote:
> >> >> Here is the console log :
> >> > [...]
> >> >> Running bootscript from mmc ...
> >> >> ## Executing script at 82000000
> >> >> Non-mainline u-boot or old-style mainline u-boot detected.
> >> >> This boot script uses the unified bootcmd handling of mainline
> >> >> u-boot >=v2014.10, which is not available on your system.
> >> >> Please boot the installer manually.
> >> > [...]
> >> >
> >> > It seems that this script isn't expected to work with the version of
> >> > u-boot that's installed on your BBB. (Which is a shame, but maybe
> >> > unavoidable.) That message could probably be improved, though.
> >>
> >> I could have misunderstood but I thought beaglebone black was loading
> >> uboot from sd-card (or emmc), and the log shows
> >>
> >> U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:13:27)
> >>
> >> which seems to be the one provided with d-i ...
> >
> > Yes, that is the u-boot version in Jessie. It seems like the
> > upstream BBB u-boot maintainer has not made the move towards
> > using the unified boot environment (config_distro_bootcmd.h)
> > which was introduced with u-boot 2014.10 and which is used by
> > many other platforms, so the BeagleBoneBlack still uses the old
> > platform-specific default environment in u-boot 2014.10. The
> > boot script used by the installer depends on the new unified boot
> > environment, which is why you get the error message quoted above.
> >
> > Vagrant, could you perhaps take a look at the issue?
>
> Did some troubleshooting (far more than I expected, now I remember why I
> hadn't already done this for BBB), and came up with a patch for u-boot
> that makes it work with d-i by emulating some distro bootcmd variables
> (similar to the patch for wandboard), and a small patch to flash kernel
> to support the change in how the "bootpart" variable is used.
>
> I've tested that it boots the armhf daily hd-media installer and boots
> an installed system. I could upload a new version of u-boot if it's
> deemed worth it; otherwise we'll just need more complicated instructions
> for manually loading the installer on d-i. FWIW, The netboot media via
> tftp works without any changes.
>
> If the user ever used u-boot's "saveenv" command, it may take
> considerable effort resetting the environment using "env default -a"
> followed by manually setting board_name, findfdt and/or fdtfile
> variables so that it detects the correct .dtb. I didn't have consistant
> success zeroing out the boot device, but in theory that should work too.
I had hoped to be able to spend some more time on the issue
today, but things didn't work out as planned and as things are
looking curently, I probably won't be able to dedicate time to it
tomorrow as well.
As the deadline for d-i-relevant changes is Friday, the question
is what to do now. AFAICS due to the necessity to change the BBB
boot script in flash-kernel when the patch is applied to u-boot,
both flash-kernel and u-boot would have to enter Jessie in
lockstep. As there is not enough time for regular migration to
Jessie, the release team would have to urgent both packages in
addition to an unblock to keep the deadline. The involved DDs
are in vastly different timezones, which makes all this even more
problematic. As stated above, I probably won't be able to take
care of flash-kernel in time, so unless Ian would like to handle
that, I do not see a a realistic chance to get this solved for
Jessie.
Ian, what is your take on the issue?
Regards,
Karsten
> Index: u-boot/include/configs/am335x_evm.h
> ===================================================================
> --- u-boot.orig/include/configs/am335x_evm.h
> +++ u-boot/include/configs/am335x_evm.h
> @@ -75,7 +75,7 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> DEFAULT_LINUX_BOOT_ENV \
> "boot_fdt=try\0" \
> - "bootpart=0:2\0" \
> + "bootpart=2\0" \
> "bootdir=/boot\0" \
> "bootfile=zImage\0" \
> "fdtfile=undefined\0" \
> @@ -85,6 +85,7 @@
> "name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}\0" \
> "optargs=\0" \
> "mmcdev=0\0" \
> + "boot_targets=mmc0 mmc1\0" \
> "mmcroot=/dev/mmcblk0p2 ro\0" \
> "mmcrootfstype=ext4 rootwait\0" \
> "rootpath=/export/rootfs\0" \
> @@ -115,7 +116,7 @@
> "loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0" \
> "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
> "source ${loadaddr}\0" \
> - "loadbootenv=load mmc ${bootpart} ${loadaddr} ${bootenv}\0" \
> + "loadbootenv=load mmc ${mmcdev}:${bootpart} ${loadaddr} ${bootenv}\0" \
> "importbootenv=echo Importing environment from mmc ...; " \
> "env import -t -r $loadaddr $filesize\0" \
> "ramargs=setenv bootargs console=${console} " \
> @@ -123,12 +124,12 @@
> "root=${ramroot} " \
> "rootfstype=${ramrootfstype}\0" \
> "loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
> - "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
> - "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
> + "loadimage=load mmc ${mmcdev}:${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
> + "loadfdt=load mmc ${mmcdev}:${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
> "script=boot.scr\0" \
> "scriptfile=${script}\0" \
> "loadbootscript=" \
> - "load mmc ${bootpart} ${loadaddr} ${scriptfile};\0" \
> + "load mmc ${mmcdev}:${bootpart} ${loadaddr} ${scriptfile};\0" \
> "bootscript=echo Running bootscript from mmc ...; " \
> "source ${loadaddr}\0" \
> "mmcloados=run mmcargs; " \
> @@ -146,6 +147,7 @@
> "bootz; " \
> "fi;\0" \
> "mmcboot=mmc dev ${mmcdev}; " \
> + "setenv devnum ${mmcdev}; " \
> "if mmc rescan; then " \
> "echo SD/MMC found on device ${mmcdev};" \
> "if run loadbootscript; then " \
> @@ -206,13 +208,14 @@
>
> #define CONFIG_BOOTCOMMAND \
> "run findfdt; " \
> + "setenv devtype mmc; " \
> "run mmcboot;" \
> - "setenv bootpart 0:1; " \
> + "setenv bootpart 1; " \
> "run mmcboot;" \
> "setenv mmcdev 1; " \
> - "setenv bootpart 1:2; " \
> + "setenv bootpart 2; " \
> "run mmcboot;" \
> - "setenv bootpart 1:1; " \
> + "setenv bootpart 1; " \
> "run mmcboot;" \
> "run nandboot;"
>
>
>
> And flash-kernel will require the following patch to maintain
> compatibility with the change in the use of bootpart:
>
> diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
> index 1d079f8..9181ccc 100644
> --- a/bootscript/bootscr.beaglebone
> +++ b/bootscript/bootscr.beaglebone
> @@ -11,7 +11,13 @@ then
> fi
>
> setenv device mmc
> -setenv partition ${bootpart}
> +if test "${devnum}" = ""
> +then
> + setenv partition ${bootpart}
> +else
> + setenv partition ${devnum}:${bootpart}
> +fi
> +
> setenv bootargs ${bootargs} @@LINUX_KERNEL_CMDLINE@@
>
> image_locations='/boot/ /'
--
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: