[meta-fsl-arm][RFC][PATCH] image_types_fsl: Add extlinux support

[meta-fsl-arm][RFC][PATCH] image_types_fsl: Add extlinux support

[Nikolay Dimitrov]

Add support for booting via extlinux. This feature is supported only for U-Boot.
Here is how it works - during boot U-Boot scans through a list of boot drives
to find a partition containing the extlinux config file (this partition
should be either marked as a bootable, or should be the 1st one of all the
non-bootable partitions on the disk). The extlinux.conf file should be located
on one of the following paths:

/boot/extlinux/extlinux.conf
/extlinux/extlinux.conf

This patch uses the /extlinux/extlinux.conf path, in order to avoid funny paths
(/boot/boot/...) if later the vfat bootable partition needs to be mounted
(usually done at /boot).

Here's an example extlinux.conf:

default yocto
label yocto
        kernel /zImage
        devicetree /imx6dl-riotboard.dtb
        append console=ttymxc1,115200 root=/dev/mmcblk0p2 rw

And this is an example machine.conf that can use extlinux boot mechanism:

EXTLINUX_CONF = "yes"
EXTLINUX_DEVICETREE = "imx6dl-riotboard.dtb"
EXTLINUX_CONSOLE = "ttymxc1,115200"
EXTLINUX_ROOTDEV = "/dev/mmcblk0p2 rw"

Advantages:
- Boot parameters are not hardcoded in the bootloader and can be managed by
  userspace tools (including package managers)
- One board can have multiple boot configurations
- Others?

Disadvantages:
- My patch generates a simplified extlinux.conf with only 1 boot configuration.
  Would be nice if we can have board-specific extlinux.conf, but I couldn't
  find a proper way to do it
- Boot params (devicetree, console) are duplicated because the extlinux/kernel
  needs them in a format different from the existing in the machine.conf
- Others?

Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
---
 classes/image_types_fsl.bbclass |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/classes/image_types_fsl.bbclass b/classes/image_types_fsl.bbclass
index 331f739..9cd9275 100644
--- a/classes/image_types_fsl.bbclass
+++ b/classes/image_types_fsl.bbclass
@@ -179,6 +179,38 @@ generate_imx_sdcard () {
 		done
 	fi
 
+	# Create extlinux config file
+	if [ "${IMAGE_BOOTLOADER}" = "u-boot" ]; then
+		if test -n "${EXTLINUX_CONF}"; then
+			if [ -z "${EXTLINUX_DEVICETREE}" ]; then
+				bberror "EXTLINUX_DEVICETREE is not defined."
+				exit 1
+			fi
+
+			if [ -z "${EXTLINUX_CONSOLE}" ]; then
+				bberror "EXTLINUX_CONSOLE is not defined."
+				exit 1
+			fi
+
+			if [ -z "${EXTLINUX_ROOTDEV}" ]; then
+				bberror "EXTLINUX_ROOTDEV is not defined."
+				exit 1
+			fi
+
+			cat > ${WORKDIR}/extlinux.conf <<EOF
+default yocto
+
+label yocto
+	kernel /${KERNEL_IMAGETYPE}
+	devicetree /${EXTLINUX_DEVICETREE}
+	append console=${EXTLINUX_CONSOLE} root=${EXTLINUX_ROOTDEV}
+EOF
+
+			mmd -i ${WORKDIR}/boot.img ::/extlinux
+			mcopy -i ${WORKDIR}/boot.img -s ${WORKDIR}/extlinux.conf ::/extlinux/
+		fi
+	fi
+
 	# Burn Partition
 	dd if=${WORKDIR}/boot.img of=${SDCARD} conv=notrunc,fsync seek=1 bs=$(expr ${IMAGE_ROOTFS_ALIGNMENT} \* 1024)
 	dd if=${SDCARD_ROOTFS} of=${SDCARD} conv=notrunc,fsync seek=1 bs=$(expr ${BOOT_SPACE_ALIGNED} \* 1024 + ${IMAGE_ROOTFS_ALIGNMENT} \* 1024)
-- 
1.7.10.4

Re: [meta-fsl-arm][RFC][PATCH] image_types_fsl: Add extlinux support

[Otavio Salvador]

Hello Nikolay,

On Fri, Aug 28, 2015 at 7:35 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Add support for booting via extlinux. This feature is supported only for U-Boot.
> Here is how it works - during boot U-Boot scans through a list of boot drives
> to find a partition containing the extlinux config file (this partition
> should be either marked as a bootable, or should be the 1st one of all the
> non-bootable partitions on the disk). The extlinux.conf file should be located
> on one of the following paths:
>
> /boot/extlinux/extlinux.conf
> /extlinux/extlinux.conf
>
> This patch uses the /extlinux/extlinux.conf path, in order to avoid funny paths
> (/boot/boot/...) if later the vfat bootable partition needs to be mounted
> (usually done at /boot).
>
> Here's an example extlinux.conf:
>
> default yocto
> label yocto
>         kernel /zImage
>         devicetree /imx6dl-riotboard.dtb
>         append console=ttymxc1,115200 root=/dev/mmcblk0p2 rw
>
> And this is an example machine.conf that can use extlinux boot mechanism:
>
> EXTLINUX_CONF = "yes"
> EXTLINUX_DEVICETREE = "imx6dl-riotboard.dtb"
> EXTLINUX_CONSOLE = "ttymxc1,115200"
> EXTLINUX_ROOTDEV = "/dev/mmcblk0p2 rw"
>
> Advantages:
> - Boot parameters are not hardcoded in the bootloader and can be managed by
>   userspace tools (including package managers)
> - One board can have multiple boot configurations
> - Others?
>
> Disadvantages:
> - My patch generates a simplified extlinux.conf with only 1 boot configuration.
>   Would be nice if we can have board-specific extlinux.conf, but I couldn't
>   find a proper way to do it
> - Boot params (devicetree, console) are duplicated because the extlinux/kernel
>   needs them in a format different from the existing in the machine.conf
> - Others?
>
> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>

First I would like to thank you

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm][RFC][PATCH] image_types_fsl: Add extlinux support

[Otavio Salvador]

Hello Nikolay,

(pressed too soon, Send)

On Mon, Aug 31, 2015 at 1:27 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Fri, Aug 28, 2015 at 7:35 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Add support for booting via extlinux. This feature is supported only for U-Boot.
>> Here is how it works - during boot U-Boot scans through a list of boot drives
>> to find a partition containing the extlinux config file (this partition
>> should be either marked as a bootable, or should be the 1st one of all the
>> non-bootable partitions on the disk). The extlinux.conf file should be located
>> on one of the following paths:
>>
>> /boot/extlinux/extlinux.conf
>> /extlinux/extlinux.conf
>>
>> This patch uses the /extlinux/extlinux.conf path, in order to avoid funny paths
>> (/boot/boot/...) if later the vfat bootable partition needs to be mounted
>> (usually done at /boot).
>>
>> Here's an example extlinux.conf:
>>
>> default yocto
>> label yocto
>>         kernel /zImage
>>         devicetree /imx6dl-riotboard.dtb
>>         append console=ttymxc1,115200 root=/dev/mmcblk0p2 rw
>>
>> And this is an example machine.conf that can use extlinux boot mechanism:
>>
>> EXTLINUX_CONF = "yes"
>> EXTLINUX_DEVICETREE = "imx6dl-riotboard.dtb"
>> EXTLINUX_CONSOLE = "ttymxc1,115200"
>> EXTLINUX_ROOTDEV = "/dev/mmcblk0p2 rw"
>>
>> Advantages:
>> - Boot parameters are not hardcoded in the bootloader and can be managed by
>>   userspace tools (including package managers)
>> - One board can have multiple boot configurations
>> - Others?
>>
>> Disadvantages:
>> - My patch generates a simplified extlinux.conf with only 1 boot configuration.
>>   Would be nice if we can have board-specific extlinux.conf, but I couldn't
>>   find a proper way to do it
>> - Boot params (devicetree, console) are duplicated because the extlinux/kernel
>>   needs them in a format different from the existing in the machine.conf
>> - Others?
>>
>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>
> First I would like to thank you

... for working on this.

This is something we should really get moving and this is a very good base.

However, I think we ought to reuse the syslinux class for this. Is it
possible for you to take a look on this?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [meta-fsl-arm][RFC][PATCH] image_types_fsl: Add extlinux support

[Nikolay Dimitrov]

Hi Otavio,

On 08/31/2015 10:28 PM, Otavio Salvador wrote:
> Hello Nikolay,
>
> (pressed too soon, Send)
>
> On Mon, Aug 31, 2015 at 1:27 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Fri, Aug 28, 2015 at 7:35 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>> Add support for booting via extlinux. This feature is supported only for U-Boot.
>>> Here is how it works - during boot U-Boot scans through a list of boot drives
>>> to find a partition containing the extlinux config file (this partition
>>> should be either marked as a bootable, or should be the 1st one of all the
>>> non-bootable partitions on the disk). The extlinux.conf file should be located
>>> on one of the following paths:
>>>
>>> /boot/extlinux/extlinux.conf
>>> /extlinux/extlinux.conf
>>>
>>> This patch uses the /extlinux/extlinux.conf path, in order to avoid funny paths
>>> (/boot/boot/...) if later the vfat bootable partition needs to be mounted
>>> (usually done at /boot).
>>>
>>> Here's an example extlinux.conf:
>>>
>>> default yocto
>>> label yocto
>>>          kernel /zImage
>>>          devicetree /imx6dl-riotboard.dtb
>>>          append console=ttymxc1,115200 root=/dev/mmcblk0p2 rw
>>>
>>> And this is an example machine.conf that can use extlinux boot mechanism:
>>>
>>> EXTLINUX_CONF = "yes"
>>> EXTLINUX_DEVICETREE = "imx6dl-riotboard.dtb"
>>> EXTLINUX_CONSOLE = "ttymxc1,115200"
>>> EXTLINUX_ROOTDEV = "/dev/mmcblk0p2 rw"
>>>
>>> Advantages:
>>> - Boot parameters are not hardcoded in the bootloader and can be managed by
>>>    userspace tools (including package managers)
>>> - One board can have multiple boot configurations
>>> - Others?
>>>
>>> Disadvantages:
>>> - My patch generates a simplified extlinux.conf with only 1 boot configuration.
>>>    Would be nice if we can have board-specific extlinux.conf, but I couldn't
>>>    find a proper way to do it
>>> - Boot params (devicetree, console) are duplicated because the extlinux/kernel
>>>    needs them in a format different from the existing in the machine.conf
>>> - Others?
>>>
>>> Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
>>
>> First I would like to thank you
>
> ... for working on this.
>
> This is something we should really get moving and this is a very good base.
>
> However, I think we ought to reuse the syslinux class for this. Is it
> possible for you to take a look on this?

Sure, I'll look at it.

Regards,
Nikolay