[U-Boot] [PATCH 2/4] am335x_evm: scan more partitions and use uname_r
Jason Kridner
jkridner at gmail.com
Sat Mar 10 16:34:48 UTC 2018
On Wed, Mar 7, 2018 at 9:27 AM Tom Rini <trini at konsulko.com> wrote:
> On Wed, Mar 07, 2018 at 05:40:42AM -0500, Jason Kridner wrote:
>
> > This enables mainline u-boot to boot the BeagleBoard.org Debian
> > distribution builds without extensive environment modifications.
> >
> > Some boot layouts only have a single partition on the
> > MMC/eMMC. This will scan those partitions after the second
> > partition that was already being scanned.
> >
> > Some layouts use uname_r to define the kernel being used for the boot to
> > support multiple kernels stored within the boot file system without
> > using symlinks.
> >
> > See http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 for
> > more details on the BeagleBoard.org Debian image layout.
> >
> > Signed-off-by: Jason Kridner <jdk at ti.com>
> > Cc: Robert Nelson <robertcnelson at gmail.com>
> > Cc: Tom Rini <trini at konsulko.com>
> > ---
> > include/configs/am335x_evm.h | 5 ++++-
> > include/environment/ti/mmc.h | 13 +++++++++----
> > 2 files changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> > index 8d45b6fade..32fe0e0cd5 100644
> > --- a/include/configs/am335x_evm.h
> > +++ b/include/configs/am335x_evm.h
> > @@ -61,7 +61,10 @@
> > #define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \
> > "bootcmd_" #devtypel #instance "=" \
> > "setenv mmcdev " #instance"; "\
> > - "setenv bootpart " #instance":2 ; "\
> > + "setenv bootpart " #instance":2; "\
> > + "run mmcboot;"\
> > + "setenv mmcdev " #instance"; "\
> > + "setenv bootpart " #instance":1; "\
> > "run mmcboot\0"
> >
> > #define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \
> > diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
> > index 4305ebdaaf..b803ecccb7 100644
> > --- a/include/environment/ti/mmc.h
> > +++ b/include/environment/ti/mmc.h
> > @@ -23,9 +23,10 @@
> > "bootenvfile=uEnv.txt\0" \
> > "importbootenv=echo Importing environment from mmc${mmcdev} ...; "
> \
> > "env import -t ${loadaddr} ${filesize}\0" \
> > - "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}\0" \
> > - "loadimage=load ${devtype} ${bootpart} ${loadaddr}
> ${bootdir}/${bootfile}\0" \
> > - "loadfdt=load ${devtype} ${bootpart} ${fdtaddr}
> ${bootdir}/${fdtfile}\0" \
> > + "loadbootenv=if fatload mmc ${mmcdev} ${loadaddr}
> ${bootdir}/${bootenvfile}; then echo Found ${bootdir}/${bootenvfile} in FAT
> partition; else load mmc ${mmcdev} ${loadaddr} ${bootdir}/${bootenvfile};
> fi\0" \
> > + "loadimage=if test -n ${uname_r}; then load ${devtype} ${bootpart}
> ${loadaddr} ${bootdir}/vmlinuz-${uname_r}; run loadrd; else load ${devtype}
> ${bootpart} ${loadaddr} ${bootdir}/${bootfile}; fi\0" \
> > + "loadrd=load ${devtype} ${bootpart} ${rdaddr}
> ${bootdir}/initrd.img-${uname_r}; setenv rdsize ${filesize}\0" \
> > + "loadfdt=if test -n ${uname_r}; then load ${devtype} ${bootpart}
> ${fdtaddr} ${bootdir}/dtbs/${uname_r}/${fdtfile}; else load ${devtype}
> ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}; fi;\0" \
> > "envboot=mmc dev ${mmcdev}; " \
> > "if mmc rescan; then " \
> > "echo SD/MMC found on device ${mmcdev};" \
> > @@ -45,7 +46,11 @@
> > "mmcloados=run args_mmc; " \
> > "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
> " \
> > "if run loadfdt; then " \
> > - "bootz ${loadaddr} - ${fdtaddr}; " \
> > + "if test -n ${uname_r}; then " \
> > + "bootz ${loadaddr}
> ${rdaddr}:${rdsize} ${fdtaddr}; " \
> > + "else " \
> > + "bootz ${loadaddr} - ${fdtaddr}; "
> \
> > + "fi; " \
> > "else " \
> > "if test ${boot_fdt} = try; then " \
> > "bootz; " \
>
> Why does this all differ from the usual Debian case? Thanks!
>
I believe the distros typically use /boot/extlinux/extlinux.conf. We need
some way to specify a number of other environment variables we use
elsewhere in our u-boot scripts for applying device-tree overlays and such.
This patch doesn't comprehend that. It does at least get our images to boot
without applying any overlays in u-boot.
I believe Robert is preparing a subsequent series to add the application of
overlays.
Do you have something else in mind with regards to envboot's future?
>
> --
> Tom
>
--
https://beagleboard.org/about
More information about the U-Boot
mailing list