Re: [PATCH 1/2] Add support for the CuBox-i.
On Fri, 2014-05-30 at 17:27 +0200, Steve Langasek wrote:
> ---
> bootscript/bootscr.cubox | 22 ++++++++++++++++++++++
> db/all.db | 17 +++++++++++++++++
> debian/changelog | 6 ++++++
> 3 files changed, 45 insertions(+)
> create mode 100644 bootscript/bootscr.cubox
>
> 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.
> +run autodetectfdt;
> +if run loadbootenv; then
> + run importbootenv;
> +fi;
> +setenv bootfile zImage;
> +if run loadbootfile; then
> + run mmcboot;
> +fi;
> 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?
> +Kernel-Flavors: armmp
What CPU core does this thing have and does it support LPAE? If so then
I think armmp-lpae should be listed here too, even if the board has <4G
someone might still install it (e.g. for XN support or by mistake etc).
> +# 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?
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?
Is this filename the same for both of the Machine names?
> +#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.
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.
> +Required-Packages: u-boot-tools
> +Bootloader-Sets-Incorrect-Root: no
> +
> Machine: Thecus N2100
> Method: redboot
> Kernel-Flavors: iop32x
> diff --git a/debian/changelog b/debian/changelog
> index 3fcba0a..09efe83 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +flash-kernel (3.20) UNRELEASED; urgency=medium
> +
> + * Add support for the CuBox-i.
> +
> + -- Steve Langasek <vorlon@debian.org> Fri, 30 May 2014 16:23:29 +0200
> +
> flash-kernel (3.19) unstable; urgency=low
>
> * Support kernel flavours with a hyphen in (e.g. armmp-lpae).
Reply to: