Fwd: Setting up Mender on a Rockchip RK3399 without using Yocto, have a few questions regarding U-boot

463 views

Skip to first unread message

Javier Talens

unread,

Sep 14, 2017, 6:42:38 AM9/14/17

to mender

Forwarded conversation
Subject: Setting up Mender on a Rockchip RK3399 without using Yocto, have a few questions regarding U-boot
------------------------

From: <arnstei...@gmail.com>
Date: Mon, Jul 24, 2017 at 11:57 AM
To: mender <men...@lists.mender.io>

So far I have set up the Mender server and the Mender client, and the client is able to get updates from the server and install them.

However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly. As I have no previous experience with U-boot, I am very confused regarding this part.

My partition layout is like this:

mmcblk1p1 has loader1 (idbloader.img)

mmcblk1p4 has loader2 (uboot.img)

mmcblk1p6 has kernel

mmcblk1p7 and mmcblk1p8 has rootfs

My questions:

1. Have anyone previously set up Mender for a Rockchip board, preferably RK3399?

2. Do I have to add the uboot.env file to mmcblk1p4, directly after uboot.img? If not, where?

3. Since it is said that you should load the kernel from each rootfs in /boot, can I just delete the partition with the kernel, mmcblk1p6? If so, do I set the boot flag on both 1p7 and 1p8 when partitioning? Will Mender change the boot flag?

4. When adding mmcblk1p4 to /etc/fstab to mount to /uboot, the system won't boot. Is that not the correct partition to mount as /uboot in my case?

5. What else is do I have to consider when setting it up?

However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly.

Can you share some details as to what happens here ^

On Monday, July 24, 2017 at 11:57:28 AM UTC+2, arnstei...@gmail.com wrote:

So far I have set up the Mender server and the Mender client, and the client is able to get updates from the server and install them.
However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly. As I have no previous experience with U-boot, I am very confused regarding this part.

My partition layout is like this:
mmcblk1p1 has loader1 (idbloader.img)
mmcblk1p4 has loader2 (uboot.img)
mmcblk1p6 has kernel
mmcblk1p7 and mmcblk1p8 has rootfs

My questions:
1. Have anyone previously set up Mender for a Rockchip board, preferably RK3399?
2. Do I have to add the uboot.env file to mmcblk1p4, directly after uboot.img? If not, where?
3. Since it is said that you should load the kernel from each rootfs in /boot, can I just delete the partition with the kernel, mmcblk1p6? If so, do I set the boot flag on both 1p7 and 1p8 when partitioning? Will Mender change the boot flag?
4. When adding mmcblk1p4 to /etc/fstab to mount to /uboot, the system won't boot. Is that not the correct partition to mount as /uboot in my case?
5. What else is do I have to consider when setting it up?

When running fw_printenv, the variables have been changed correctly, however, it is still not booting to the correct rootfs. I have tried changing the bootcommand to always reference the variables like ${mender_uboot_root} and ${mender_kernel_root} where appropriate, but still nothing. If I run Mender as a systemd service this ends up setting the device in a reboot loop, as every time it boots it sees that there is an update version mismatch. This again suggests that the bootcount variable is not updated.

On Monday, 24 July 2017 12:53:35 UTC+2, gr...@mender.io wrote:

However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly.

Can you share some details as to what happens here ^

On Monday, July 24, 2017 at 11:57:28 AM UTC+2, arnstei...@gmail.com wrote:
So far I have set up the Mender server and the Mender client, and the client is able to get updates from the server and install them.
However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly. As I have no previous experience with U-boot, I am very confused regarding this part.

My partition layout is like this:
mmcblk1p1 has loader1 (idbloader.img)
mmcblk1p4 has loader2 (uboot.img)
mmcblk1p6 has kernel
mmcblk1p7 and mmcblk1p8 has rootfs

My questions:
1. Have anyone previously set up Mender for a Rockchip board, preferably RK3399?
2. Do I have to add the uboot.env file to mmcblk1p4, directly after uboot.img? If not, where?
3. Since it is said that you should load the kernel from each rootfs in /boot, can I just delete the partition with the kernel, mmcblk1p6? If so, do I set the boot flag on both 1p7 and 1p8 when partitioning? Will Mender change the boot flag?
4. When adding mmcblk1p4 to /etc/fstab to mount to /uboot, the system won't boot. Is that not the correct partition to mount as /uboot in my case?
5. What else is do I have to consider when setting it up?

when you apply an update, does u-boot boot successfully, but you end up in the original partition? (as in no partition swap is performed)

On Monday, July 24, 2017 at 1:20:39 PM UTC+2, arnstei...@gmail.com wrote:

When running fw_printenv, the variables have been changed correctly, however, it is still not booting to the correct rootfs. I have tried changing the bootcommand to always reference the variables like ${mender_uboot_root} and ${mender_kernel_root} where appropriate, but still nothing. If I run Mender as a systemd service this ends up setting the device in a reboot loop, as every time it boots it sees that there is an update version mismatch. This again suggests that the bootcount variable is not updated.

On Monday, 24 July 2017 12:53:35 UTC+2, gr...@mender.io wrote:
However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly.

Can you share some details as to what happens here ^

On Monday, July 24, 2017 at 11:57:28 AM UTC+2, arnstei...@gmail.com wrote:
So far I have set up the Mender server and the Mender client, and the client is able to get updates from the server and install them.
However, it does not change rootfs after the update is applied, which is due to U-boot not being set up correctly. As I have no previous experience with U-boot, I am very confused regarding this part.

My partition layout is like this:
mmcblk1p1 has loader1 (idbloader.img)
mmcblk1p4 has loader2 (uboot.img)
mmcblk1p6 has kernel
mmcblk1p7 and mmcblk1p8 has rootfs

My questions:
1. Have anyone previously set up Mender for a Rockchip board, preferably RK3399?
2. Do I have to add the uboot.env file to mmcblk1p4, directly after uboot.img? If not, where?
3. Since it is said that you should load the kernel from each rootfs in /boot, can I just delete the partition with the kernel, mmcblk1p6? If so, do I set the boot flag on both 1p7 and 1p8 when partitioning? Will Mender change the boot flag?
4. When adding mmcblk1p4 to /etc/fstab to mount to /uboot, the system won't boot. Is that not the correct partition to mount as /uboot in my case?
5. What else is do I have to consider when setting it up?

Yes, that's exactly what happens. It does not brick the device or anything, it just goes back to the original partition. And when I run Mender it sees that there was an update, and then reboots.

To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/bc795cfa-c0d9-40cb-bfd3-4dabf7e26f02%40lists.mender.io.

----------
From: <arns...@yoimo.no>
Date: Mon, Jul 24, 2017 at 2:29 PM
To: mender <men...@lists.mender.io>
Cc: arnstei...@gmail.com, gr...@mender.io

Here's a patch with what I've changed. I tried copying the QEMU patch as much as possible.

https://gist.github.com/arnstein/85b56ebb0d919e58408138303f879df3

In this version I have included distro_bootcmd after rk_boot. This will always end up with boot_extlinux which runs sysboot. If I do not include distro_bootcmd it will not boot at all. (the reason for adding this is because I tried using root=${mender_kernel_root} in the extlinux.conf file as a desperate attempt at booting the correct partition)

To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/a77e26ba-23a2-451c-88c9-4e65c13263eb%40lists.mender.io.

----------
From: <arnstei...@gmail.com>
Date: Mon, Jul 24, 2017 at 2:39 PM
To: mender <men...@lists.mender.io>
Cc: arnstei...@gmail.com, gr...@mender.io

Here's a patch with what I've changed. I tried copying the QEMU patch as much as possible.

On Monday, 24 July 2017 13:38:53 UTC+2, arnstei...@gmail.com wrote:

To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/72af275f-ed4a-41b6-8ba6-4a87f5234163%40lists.mender.io.

----------
From: Maciej Borzecki <maciej....@mender.io>
Date: Mon, Jul 24, 2017 at 3:41 PM
To: arns...@yoimo.no
Cc: mender <men...@lists.mender.io>, arnstei...@gmail.com, gr...@mender.io

On Mon, Jul 24, 2017 at 2:29 PM, <arns...@yoimo.no> wrote:
> Here's a patch with what I've changed. I tried copying the QEMU patch as
> much as possible.
> https://gist.github.com/arnstein/85b56ebb0d919e58408138303f879df3
>
> In this version I have included distro_bootcmd after rk_boot. This will
> always end up with boot_extlinux which runs sysboot. If I do not include
> distro_bootcmd it will not boot at all. (the reason for adding this is
> because I tried using root=${mender_kernel_root} in the extlinux.conf file
> as a desperate attempt at booting the correct partition)
>
>

I'd recommend taking a step back and start slowly from the beginning.

Mender is using fw_setenv/fw_printenv for integrating with u-boot in
userspace. You must have a working u-boot-fw-utils configuration. IOW
whatever you set by using fw_setenv must be visible when you do a
printenv at u-boot prompt. In your original, working image, make sure
that you have a configuration that works:
* CONFIG_ENV_IS_IN_MMC is set
* CONFIG_SYS_ENV_MMC_DEV is set to something reasonable, such as a
device that you will the firmware from
* /etc/fw_env.config points to correct devices with correct offsets

The next step is making sure that u-boot script makes sense, that is
(given your partitioning setup):
- kernel will be loaded from mmc 1:6
- rootfs will be either mmc 1:7 or mmc 1:8
- make sure that MENDER_ROOTFS_PART_A and MENDER_ROOTFS_PART_B are set
accordingly

Unless you're planning on supporting all available boot options, it
usually makes sense to trim default boot script to just the essential
parts.
For example start with this (rough guess based on
https://github.com/rockchip-linux/u-boot and
https://github.com/rockchip-linux/meta-rockchip/:

bootcmd=run mmcboot; reset
mmcboot=load mmc 1:6 ${kernel_addr_r} zImage; load mmc 1:6
${fdt_addr_r} <your-dtb>; setenv bootargs root=/dev/mmcblk1p7
console=<your-console-settings>; bootz ${kernel_addr_r} -
${fdt_addr_r}

Once you integrate with mender u-boot support you'll get to something like this:
bootcmd=run mender_setup; run mmcboot; reset
mmcboot=load ${mender_uboot_root} ${kernel_addr_r} zImage; load
${mender_uboot_root} ${fdt_addr_r} <your-dtb>; setenv bootargs
root=${kender_kernel_root} console=<your-console-settings>; bootz
${kernel_addr_r} - ${fdt_addr_r}

Also, with your partitioning setup, you will need to skip building
mender sdimg image and use your own.
https://github.com/rockchip-linux/meta-rockchip/blob/master/classes/rockchip-gpt-img.bbclass
looks like a decent base.

--
Maciej Borzecki

--
You received this message because you are subscribed to the Google Groups "mender" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.
To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/CALJJLGJcDCCFUxupXoffTwnAn0MsLwQT02ij6FV3-qjrvONctw%40mail.gmail.com.

----------
From: <arnstei...@gmail.com>
Date: Mon, Jul 24, 2017 at 5:30 PM
To: mender <men...@lists.mender.io>
Cc: arns...@yoimo.no, arnstei...@gmail.com, gr...@mender.io

Thank you very much for your reply!

CONFIG_SYS_ENV_MMC_DEV is not set at all in my configuration! What is it supposed to be? U-boot syntax device, like "mmc 0"?

My fw_env.config consists of the line:

"/uboot/uboot.env 0x0000 0x20000"

Should that also include other things?

My boot command is like this now:

#define CONFIG_BOOTCOMMAND \

"run mender_setup; " \

"load ${mender_uboot_root} ${kernel_addr_r} ${mender_boot_root}/boot/Image; " \

"load ${mender_uboot_root} ${fdt_addr_r} ${mender_boot_root}/boot/rk3399-firefly-linux.dtb; " \

"setenv bootargs root=${mender_kernel_root} console=ttyFIQ0,1500000n8; " \

"booti ${kernel_addr_r} - ${fdt_addr_r} ; " \

"reset;\

"run mender_try_to_recover;"

After finally getting a serial to USB cable I can see now that everything is loaded from mmc 0 in Uboot, not mmc1.

I am also wondering on question 2 and 4 in the original post:

2. Do I have to add the uboot.env file to mmcblk1p4, directly after uboot.img? If not, where?

4. When adding mmcblk1p4 to /etc/fstab to mount to /uboot, the system won't boot. Is that not the correct partition to mount as /uboot in my case?

Arnstein

On Monday, 24 July 2017 15:41:36 UTC+2, Maciej Borzecki wrote:

To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/ece0d4a0-37bd-413e-8126-a47987b422a4%40lists.mender.io.

----------
From: <gr...@mender.io>
Date: Tue, Jul 25, 2017 at 9:42 AM
To: mender <men...@lists.mender.io>
Cc: arns...@yoimo.no, arnstei...@gmail.com, gr...@mender.io

CONFIG_SYS_ENV_MMC_DEV is a mistake, the actual variable is CONFIG_SYS_MMC_ENV_DEV

To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/105f0be4-a210-454e-ae35-980ba80e42e1%40lists.mender.io.

----------
From: Maciej Borzecki <maciej....@mender.io>
Date: Tue, Jul 25, 2017 at 10:01 AM
To: gr...@mender.io
Cc: mender <men...@lists.mender.io>, arns...@yoimo.no, arnstei...@gmail.com

On Tue, Jul 25, 2017 at 9:42 AM, <gr...@mender.io> wrote:
> CONFIG_SYS_ENV_MMC_DEV is a mistake, the actual variable is
> CONFIG_SYS_MMC_ENV_DEV

Yup, an unfortunate typo. CONFIG_SYS_MMC_ENV_DEV identifies which MMC
device the environment is stored on.

> To post to this group, send email to men...@lists.mender.io.
> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.mender.io/d/msgid/mender/105f0be4-a210-454e-ae35-980ba80e42e1%40lists.mender.io.

--
Maciej Borzecki

--
You received this message because you are subscribed to the Google Groups "mender" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.
To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/CALJJLGL_OVQoz45gUtr-XRK-QC1W_w%3Df%2BGj6DHwJK2KGZhUghw%40mail.gmail.com.

----------
From: <arnstei...@gmail.com>
Date: Tue, Jul 25, 2017 at 11:54 AM
To: mender <men...@lists.mender.io>
Cc: gr...@mender.io, arns...@yoimo.no, arnstei...@gmail.com

Thank you.

I think the only thing that remains now is to be able to mount the uboot.env file to /uboot. Is it enough to make a partition that starts at the location defined as MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 ?

On Tuesday, 25 July 2017 10:01:34 UTC+2, Maciej Borzecki wrote:

> To post to this group, send email to men...@lists.mender.io.
> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.mender.io/d/msgid/mender/105f0be4-a210-454e-ae35-980ba80e42e1%40lists.mender.io.

--
Maciej Borzecki

--
You received this message because you are subscribed to the Google Groups "mender" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.
To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/2e8d3d27-e965-4e7d-92ae-ef03f35de193%40lists.mender.io.

----------
From: Maciej Borzecki <maciej....@mender.io>
Date: Wed, Jul 26, 2017 at 12:47 PM
To: Arnstein Kleven <arnstei...@gmail.com>
Cc: mender <men...@lists.mender.io>, Gregorio Di Stefano <gr...@mender.io>, arns...@yoimo.no

On Tue, Jul 25, 2017 at 11:54 AM, <arnstei...@gmail.com> wrote:
> Thank you.
> I think the only thing that remains now is to be able to mount the uboot.env
> file to /uboot. Is it enough to make a partition that starts at the location
> defined as MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 ?

Not sure I follow. The usual way is to set
CONFIG_ENV_IS_IN_{FLASH,NAND,MMC,UBI} option. Then the environment
will be stored at some offset in the device.

IIRC only CONFIG_ENV_IS_IN_FAT allows to have environment in a file,
in which case you may want to mount it. I don't think you can have a
redundant environment this way though. On top of this, u-boot headers
generated by mender will not play well with this setting. I think that
the offsets will just be ignored at this point. Also, you will need to
deliver your own fw_env.config.

Cheers,
--
Maciej Borzecki

--
You received this message because you are subscribed to the Google Groups "mender" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.
To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/CALJJLGK2%2B%2BAv0T4yG77TOgZW1tSz5Sftwo33w8SZ2AJgNT_HVw%40mail.gmail.com.

----------
From: <arns...@yoimo.no>
Date: Wed, Jul 26, 2017 at 1:23 PM
To: mender <men...@lists.mender.io>
Cc: arnstei...@gmail.com, gr...@mender.io, arns...@yoimo.no

My issue right now seems to be that fw_setenv is not updating the environment. If I do fw_setenv mender_test 1 while running the OS, and then do fw_printenv, it will show the correct value, however, when I reboot and go into uboot prompt, the variable isn't there. I think this is linked to how I access my uboot.env file.

In the documentation it says:

/uboot Store the bootloader.

But when I mount the partition with the bootloader using fstab, the system won't boot.

My fw_env.config just references /uboot/uboot.env, so whatever is there will be used. If I make a directory on the file system called uboot and put an empty file of 16MB(the defined env size for me) called uboot.env there, this file will give me the environment variables, and will be updated when I'm running the OS, but since this is not the same file that uboot reads, it does not have an impact on uboot.

I am very confused on how I should do this part of the setup.

Arnstein

On Wednesday, 26 July 2017 12:47:31 UTC+2, Maciej Borzecki wrote:

On Tue, Jul 25, 2017 at 11:54 AM, <arnstei...@gmail.com> wrote:
> Thank you.
> I think the only thing that remains now is to be able to mount the uboot.env
> file to /uboot. Is it enough to make a partition that starts at the location
> defined as MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 ?

Not sure I follow. The usual way is to set
CONFIG_ENV_IS_IN_{FLASH,NAND,MMC,UBI} option. Then the environment
will be stored at some offset in the device.

IIRC only CONFIG_ENV_IS_IN_FAT allows to have environment in a file,
in which case you may want to mount it. I don't think you can have a
redundant environment this way though. On top of this, u-boot headers
generated by mender will not play well with this setting. I think that
the offsets will just be ignored at this point. Also, you will need to
deliver your own fw_env.config.

Cheers,
--
Maciej Borzecki

--
You received this message because you are subscribed to the Google Groups "mender" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.
To view this discussion on the web visit https://groups.google.com/a/lists.mender.io/d/msgid/mender/aaf867b2-60fc-4bb8-bf39-867472847923%40lists.mender.io.

----------
From: Kristian Amlie <kristia...@northern.tech>
Date: Mon, Aug 14, 2017 at 1:36 PM
To: arns...@yoimo.no, mender <men...@lists.mender.io>
Cc: arnstei...@gmail.com

On 26/07/17 13:23, arns...@yoimo.no wrote:
> My issue right now seems to be that fw_setenv is not updating the
> environment. If I do fw_setenv mender_test 1 while running the OS, and
> then do fw_printenv, it will show the correct value, however, when I
> reboot and go into uboot prompt, the variable isn't there. I think this
> is linked to how I access my uboot.env file.
> In the documentation it says:
> /ubootStore the bootloader.
>
> But when I mount the partition with the bootloader using fstab, the
> system won't boot.
>
> My fw_env.config just references /uboot/uboot.env, so whatever is there
> will be used. If I make a directory on the file system called uboot and
> put an empty file of 16MB(the defined env size for me) called uboot.env
> there, this file will give me the environment variables, and will be
> updated when I'm running the OS, but since this is not the same file
> that uboot reads, it does not have an impact on uboot.
>
> I am very confused on how I should do this part of the setup.

A bit late to the party, but which branch of meta-mender are you using?

--
Kristian

----------
From: <arnstei...@gmail.com>
Date: Mon, Aug 14, 2017 at 2:15 PM
To: mender <men...@lists.mender.io>
Cc: arns...@yoimo.no, arnstei...@gmail.com

I am trying to set it up without using Yocto, which means I have cloned the Uboot source, applied the patches and then compiled it.

I have been occupied with other things ever since making the last reply to this thread, but will visit your office when the focus shifts to Mender integration again :)

On Monday, 14 August 2017 13:36:22 UTC+2, Kristian Amlie wrote:

On 26/07/17 13:23, arns...@yoimo.no wrote:
> My issue right now seems to be that fw_setenv is not updating the
> environment. If I do fw_setenv mender_test 1 while running the OS, and
> then do fw_printenv, it will show the correct value, however, when I
> reboot and go into uboot prompt, the variable isn't there. I think this
> is linked to how I access my uboot.env file.
> In the documentation it says:
> /ubootStore the bootloader.
>
> But when I mount the partition with the bootloader using fstab, the
> system won't boot.
>
> My fw_env.config just references /uboot/uboot.env, so whatever is there
> will be used. If I make a directory on the file system called uboot and
> put an empty file of 16MB(the defined env size for me) called uboot.env
> there, this file will give me the environment variables, and will be
> updated when I'm running the OS, but since this is not the same file
> that uboot reads, it does not have an impact on uboot.
>
> I am very confused on how I should do this part of the setup.

A bit late to the party, but which branch of meta-mender are you using?

--
Kristian

Reply all

Reply to author

Forward

0 new messages