[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#884003: FDT overlay support



On 2017-12-12, Andre Heider wrote:
> Subject: [PATCH 06/10] beaglebone: clean up boot script
>
> Use $fk_image_locations and distro compatible variable names, get rid
> of the duplicated code from bootscr.uboot-generic, and use that script
> additionally instead.
>
> Signed-off-by: Andre Heider <a.heider@gmail.com>
> ---
>  bootscript/armhf/bootscr.beaglebone | 49 +++++--------------------------------
>  db/all.db                           |  4 +--
>  2 files changed, 8 insertions(+), 45 deletions(-)
>
> diff --git a/bootscript/armhf/bootscr.beaglebone b/bootscript/armhf/bootscr.beaglebone
> index edc1cd0..f04532d 100644
> --- a/bootscript/armhf/bootscr.beaglebone
> +++ b/bootscript/armhf/bootscr.beaglebone
...
> -if test "${devnum}" = ""
> -then
> -  setenv partition ${bootpart}
> -elif test "${distro_bootpart}" = ""
> -then
> -  # use partition provided by bootpart
> -  setenv partition ${devnum}:${bootpart}
> -else
> -  # use partition provided by distro_bootpart
> -  setenv partition ${devnum}:${distro_bootpart}
> +if test -z "${devtype}"; then
> +  setenv devtype "mmc"
>  fi
...
> +if test -z "${devnum}"; then
> +  setenv devnum ${bootpart}
>  fi

I just realized that the handling of bootpart is incorrect here...

Before distro_bootcmd support was added, bootpart sometimes contained
both a device number and a the partition:

  bootpart=0:1

Then, distro_bootcmd support was added, and it changed to:

  bootpart=1

But that broke legacy scripts, so distro_bootpart was added:

  distro_bootpart=1

This will result in this expanding incorrectly:

  load ${devtype} ${devnum}:${partition} ....

To render as this in the legacy case:

  load mmc 0:1:0:1 ....


I haven't figured out in u-boot's shell how to extract parts of
variables, and we're dealing with legacy versions of
u-boot... so... hrm.

This is a similar problem with the legacy u-boot-sunxi support in the
bootscr.sunxi with the "partition" variable.

Supporting legacy u-boot variables is a tangled mess, but u-boot is
definitely something people might be hesitant to update, at risk of
bricking a system.


live well,
  vagrant

Attachment: signature.asc
Description: PGP signature


Reply to: