On Fri, May 30, 2014 at 07:59:29PM +0100, Ian Campbell wrote:
> > diff --git a/bootscript/bootscr.cubox b/bootscript/bootscr.cubox
> > new file mode 100644
> > index 0000000..4aa27d4
> > --- /dev/null
> > +++ b/bootscript/bootscr.cubox
> > @@ -0,0 +1,22 @@
> > +setenv ramdiskaddr 0x11800000;
> > +setenv ramdisk uInitrd;
> > +setenv file_prefix;
> > +for prefix in ${boot_prefixes}; do
> > + echo Loading ${prefix}${ramdisk} to ${ramdiskaddr};
> > + if load mmc ${mmcdev}:${mmcpart} ${ramdiskaddr} ${prefix}${ramdisk}; then
> > + setenv file_prefix ${prefix};
> > + fi;
> > +done;
> > +if test -z ${file_prefix}; then
> > + echo No ramdisk found;
> > + setenv ramdiskdaddr -;
> > +fi;
> > +setenv autobootfdt echo\ Booting\ \${boot_file}\;\ if\ test\ \${boot_file}\ =\ zImage\;\ then\ bootz\ \${loadaddr}\ \${ramdiskaddr}\ \${fdt_addr}\;\ else\ bootm\ \${loadaddr}\ \${ramdiskaddr}\ \${fdt_addr}\;\ fi;
> Is all of this fallback/checking etc stuff really needed? With a
> packaged kernel we can make certain simplifying assumptions, and for a
> non-packaged kernel does f-k even work at all? I would half expect
> someone installing a kernel manually to also manually write the boot
> script.
I intended this to be a minimal modification of the (quite elaborate)
upstream default environment, extending it to support ramdisks in a way that
can potentially be integrated into upstream (eventually). We could
certainly make a simpler boot script that would be generic, but I would
prefer something that would continue to boot correctly if the user manually
replaces the kernel on disk with an unpackaged one.
> > diff --git a/db/all.db b/db/all.db
> > index 68f85b4..dce775d 100644
> > --- a/db/all.db
> > +++ b/db/all.db
> > @@ -436,6 +436,23 @@ Boot-DTB-Path: /boot/dtb
> > Required-Packages: u-boot-tools
> > Bootloader-Sets-Incorrect-Root: no
> >
> > +Machine: SolidRun i.MX 6Quad/Dual/DualLite/Solo CuBox-i Board
> > +Machine: SolidRun Cubox-i Dual/Quad
> Why are there two? Are there two possible DTBs for this board or is
> there some old board file style support too?
There is old-style support as well; SolidRun currently still makes available
a 3.0 BSP kernel, and the machine identifier is different on that kernel
than on a more recent one. Note that the first machine identifier lists all
four flavors of cubox-i, but there are two different dtbs - one for
DualLite+Solo, one for Quad+Dual. So we can't obviously detect which of the
two dtbs is right for all of the machines when running an old kernel. I
think it's still useful to default to installing the right dtb on the
duals and quads when running an old kernel, than to do nothing for any of
them.
> > +# Waits for this to be included in the kernel package
> > +#DTB-Id: imx6q-cubox-i.dtb
> This is in the 3.14 kernel in Jessie now I think?
Yes, and this should be updated to use it.
> How does it work for you without? Does the firmware also embed a DTB? I
> notice the script uses fdt_addr but doesn't load anything to it so I
> guess something like that must be happening?
The firmware does not embed a DTB; I was previously using one that was
locally built and installed, not from a kernel package, for testing
purposes. The fdt_addr variable is set, by the default cubox-i u-boot env.
> Is this filename the same for both of the Machine names?
Except for the case that for the first machine names, the filename is one of
two different ones that we can't distinguish between.
> > +#Boot-DTB-Path: /boot/imx6q-cubox-i.dtb
> > +Boot-Kernel-Path: /boot/zImage
> > +Boot-Initrd-Path: /boot/uInitrd
> > +Boot-Script-Path: /boot/boot.scr
> > +U-Boot-Initrd-Address: 0x0
> > +#FIXME: we really want initramfs support in the u-boot scripting, so we don't
> > +#have to use a script to get initramfs support
> > +U-Boot-Script-Address: 0x0
> > +U-Boot-Script-Name: bootscr.cubox
> If the u-boot supports bootz and we are happy to use it in the boot.scr
> (I think if we should when we can) then Boot-{DTB,Kernel,Initrd}-Path
> and U-Boot-Initrd-Address aren't needed.
It does use bootz. The Boot-Kernel-Path is made use of by my code changes
in the second patch, to create a symlink under a well-known location so the
bootloader can find it automatically at boot. The Boot-Initrd-Path and
U-Boot-Initrd-Address are used because I'm still creating a uInitrd, for use
with the zImage, because I didn't know about the "${filesize}" trick for the
initrd. I'll try to integrate that properly in the script and see what I
get. The Boot-DTB-Path is needed to match the default path used by cubox-i
U-Boot to locate the dtb; the only other way to load this automatically
seems to be to append it to the kernel image, which we don't otherwise need
to modify on this platform, and furthermore makes it impossible to prepare a
single image which can boot on all the cubox-i flavors.
Here's the relevant bit of u-boot include/configs/mx6_cubox-i.h:
[...]
"autodetectfdt=if test ${cpu} = 6SOLO || test ${cpu} = 6DL; then " \
"setenv fdt_prefix imx6dl; " \
"else " \
"setenv fdt_prefix imx6q; " \
"fi; " \
"if test ${board} = mx6-cubox-i; then " \
"setenv fdt_file ${fdt_prefix}-cubox-i.dtb; " \
"else " \
"setenv fdt_file ${fdt_prefix}-hummingboard.dtb; " \
"fi;\0" \
[...]
> I'm not sure I understand why U-Boot-Script-Address exists at all, I
> never use it or pass any of the relevant options to mkimage -- I suspect
> you can just drop it.
Hmm? It seems to be used in the version of flash-kernel functions I see in
trunk:
usaddr="$(get_machine_field "$machine" "U-Boot-Script-Address")" || :
[...]
case "$method" in
[...]
"generic")
[...]
if [ -n "$boot_script_path" ]; then
boot_script_path="$boot_mnt_dir/$boot_script_path"
boot_script="$BOOTSCRIPTS_DIR/$usname"
mkimage_script "$usaddr" "boot script"
"$boot_script" \
"$tmpdir/boot.scr"
boot_script="$tmpdir/boot.scr"
backup_and_install "$boot_script"
"$boot_script_path"
fi
[...]
I can certainly try dropping it, but this was consistent with existing
U-Boot Script handling at the time I wrote this.
On Fri, May 30, 2014 at 08:53:08PM +0100, Ian Campbell wrote:
> On Fri, 2014-05-30 at 12:36 -0700, Vagrant Cascadian wrote:
> > On Fri, May 30, 2014 at 07:59:29PM +0100, Ian Campbell wrote:
> > > On Fri, 2014-05-30 at 17:27 +0200, Steve Langasek wrote:
> > > > diff --git a/db/all.db b/db/all.db
> > > > index 68f85b4..dce775d 100644
> > > > --- a/db/all.db
> > > > +++ b/db/all.db
> > > > @@ -436,6 +436,23 @@ Boot-DTB-Path: /boot/dtb
> > > > Required-Packages: u-boot-tools
> > > > Bootloader-Sets-Incorrect-Root: no
> > > >
> > > > +Machine: SolidRun i.MX 6Quad/Dual/DualLite/Solo CuBox-i Board
> > > > +Machine: SolidRun Cubox-i Dual/Quad
> > > Why are there two? Are there two possible DTBs for this board or is
> > > there some old board file style support too?
> > Yes, there are two DTBs:
> > imx6dl-cubox-i.dtb imx6q-cubox-i.dtb
> > There are four different models of cubox-i: a single core, two dual core, and
> > one quad core variant. I'm not sure how exactly they map to the .dtb files,
> > I've only used the quad-core one.
> In which case it seems likely then that multiple stanzas will be needed
> to map the machine name to the appropriate dtb file. It's a bit of a
> pain to need all that repetition, perhaps one day we can sort that, but
> lets not make this stuff depend on it...
Currently, I've only written this to support the Dual and Quad. The Solo
and DualLite are not supported by this stanza, I don't have any board to
test that on (and see above re: ambiguous old naming).
Though note that based on U-Boot's detection support, applying this
flash-kernel on a Solo or DualLite won't /break/ it, it just won't make use
of this particular dtb.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature