[PATCH] configs: rockchip: rock-pi-s: enable environment

[PATCH] configs: rockchip: rock-pi-s: enable environment

[Trevor Woerner]

Following the pattern of other Rockchip devices, enable the U-Boot environment
to be stored in MMC. This patch specifically assumes the environment will be
stored on the SDcard.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 configs/rock-pi-s-rk3308_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig
index 9908a4b4f457..af2cddcc2553 100644
--- a/configs/rock-pi-s-rk3308_defconfig
+++ b/configs/rock-pi-s-rk3308_defconfig
@@ -54,7 +54,9 @@ CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CLK=y
-- 
2.43.0.76.g1a87c842ece3

[PATCH] configs: rockchip: rock3a: enable environment

[Trevor Woerner]

Following the pattern of other Rockchip devices, enable the U-Boot
environment to be stored in MMC. This patch specifically assumes the
environment will be stored on the SDcard.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 configs/rock-3a-rk3568_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig
index 28d157dbd7a7..44158a4d34f1 100644
--- a/configs/rock-3a-rk3568_defconfig
+++ b/configs/rock-3a-rk3568_defconfig
@@ -58,6 +58,8 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
-- 
2.43.0.76.g1a87c842ece3

Re: [PATCH] configs: rockchip: rock3a: enable environment

[Jonas Karlman]

Hi Trevor,

On 2024-03-05 03:10, Trevor Woerner wrote:
> Following the pattern of other Rockchip devices, enable the U-Boot
> environment to be stored in MMC. This patch specifically assumes the
> environment will be stored on the SDcard.

This board has SPI flash, so storing env in SPI flash is probably a
better default. However, preferably the env should be stored/loaded from
the same device that TPL/SPL was loaded from.

What is your use case for being able to store the env? Personally, I have
never had a need for storing an env and use ENV_IS_NOWHERE on my boards.

Regards,
Jonas

> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
>  configs/rock-3a-rk3568_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig
> index 28d157dbd7a7..44158a4d34f1 100644
> --- a/configs/rock-3a-rk3568_defconfig
> +++ b/configs/rock-3a-rk3568_defconfig
> @@ -58,6 +58,8 @@ CONFIG_CMD_REGULATOR=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIVE=y
>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_MMC_ENV_DEV=1
>  CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_SPL_SYSCON=y

[PATCH] configs: rockchip: rock5a: enable environment

[Trevor Woerner]

Following the pattern of other Rockchip devices, enable the U-Boot
environment to be stored in MMC. This patch specifically assumes the
environment will be stored on the SDcard.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 configs/rock5a-rk3588s_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
index a6471a519514..ac6411667d9a 100644
--- a/configs/rock5a-rk3588s_defconfig
+++ b/configs/rock5a-rk3588s_defconfig
@@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
+CONFIG_ENV_SIZE=0x8000
 CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
 CONFIG_ROCKCHIP_RK3588=y
 CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
@@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
-- 
2.43.0.76.g1a87c842ece3

Re: [PATCH] configs: rockchip: rock5a: enable environment

[Eugen Hristev]

On 3/5/24 04:10, Trevor Woerner wrote:
> Following the pattern of other Rockchip devices, enable the U-Boot
> environment to be stored in MMC. This patch specifically assumes the
> environment will be stored on the SDcard.
> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
>  configs/rock5a-rk3588s_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
> index a6471a519514..ac6411667d9a 100644
> --- a/configs/rock5a-rk3588s_defconfig
> +++ b/configs/rock5a-rk3588s_defconfig
> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
> +CONFIG_ENV_SIZE=0x8000
>  CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
>  CONFIG_ROCKCHIP_RK3588=y
>  CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> @@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIVE=y
>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_MMC_ENV_DEV=1
>  CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_SPL_SYSCON=y


Hi Trevor,

What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash ?

The rockchip pattern is usually to have a standard config for all boards and it is
not stored anywhere.

Kever, Jonas, please correct me if I am wrong.

Eugen

Re: [PATCH] configs: rockchip: rock5a: enable environment

[Jonas Karlman]

Hi,

On 2024-03-05 06:40, Eugen Hristev wrote:
> On 3/5/24 04:10, Trevor Woerner wrote:
>> Following the pattern of other Rockchip devices, enable the U-Boot
>> environment to be stored in MMC. This patch specifically assumes the
>> environment will be stored on the SDcard.
>>
>> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
>> ---
>>  configs/rock5a-rk3588s_defconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
>> index a6471a519514..ac6411667d9a 100644
>> --- a/configs/rock5a-rk3588s_defconfig
>> +++ b/configs/rock5a-rk3588s_defconfig
>> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>  CONFIG_NR_DRAM_BANKS=2
>>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
>> +CONFIG_ENV_SIZE=0x8000
>>  CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
>>  CONFIG_ROCKCHIP_RK3588=y
>>  CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>> @@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
>>  CONFIG_SPL_OF_CONTROL=y
>>  CONFIG_OF_LIVE=y
>>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>> +CONFIG_ENV_IS_IN_MMC=y
>> +CONFIG_SYS_MMC_ENV_DEV=1
>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>  CONFIG_SPL_REGMAP=y
>>  CONFIG_SPL_SYSCON=y
> 
> 
> Hi Trevor,
> 
> What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash ?

Agree, we should not blindly enable env and expect that it can be stored
on sd-card. If anything, it should preferably be saved/loaded from the
device where TPL/SPL was booted from.

Personally I always run my devices with ENV_IS_NOWHERE, with standard
boot and extlinux or efi as the preferred way to boot, I do not see why
normal end-users with a single OS really have a need for a saved env,
please educate me :-)

> 
> The rockchip pattern is usually to have a standard config for all boards and it is
> not stored anywhere.

Unfortunately lots of rockchip boards have blindly enabled ENV_IN_MMC
and force it to use sd-card. However, before enabling same forced
behavior on new boards I would recommend ensuring adding support for
allowing env to follow same load order as FIT (spl-boot-order).

Regards,
Jonas

> 
> Kever, Jonas, please correct me if I am wrong.
> 
> Eugen

Re: [PATCH] configs: rockchip: rock5a: enable environment

[Trevor Woerner]

On Tue 2024-03-05 @ 10:17:10 AM, Jonas Karlman wrote:
> Hi,
> 
> On 2024-03-05 06:40, Eugen Hristev wrote:
> > On 3/5/24 04:10, Trevor Woerner wrote:
> >> Following the pattern of other Rockchip devices, enable the U-Boot
> >> environment to be stored in MMC. This patch specifically assumes the
> >> environment will be stored on the SDcard.
> >>
> >> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> >> ---
> >>  configs/rock5a-rk3588s_defconfig | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
> >> index a6471a519514..ac6411667d9a 100644
> >> --- a/configs/rock5a-rk3588s_defconfig
> >> +++ b/configs/rock5a-rk3588s_defconfig
> >> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
> >>  CONFIG_NR_DRAM_BANKS=2
> >>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
> >> +CONFIG_ENV_SIZE=0x8000
> >>  CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
> >>  CONFIG_ROCKCHIP_RK3588=y
> >>  CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> >> @@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
> >>  CONFIG_SPL_OF_CONTROL=y
> >>  CONFIG_OF_LIVE=y
> >>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> >> +CONFIG_ENV_IS_IN_MMC=y
> >> +CONFIG_SYS_MMC_ENV_DEV=1
> >>  CONFIG_SPL_DM_SEQ_ALIAS=y
> >>  CONFIG_SPL_REGMAP=y
> >>  CONFIG_SPL_SYSCON=y
> > 
> > 
> > Hi Trevor,
> > 
> > What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash ?
> 
> Agree, we should not blindly enable env and expect that it can be stored
> on sd-card. If anything, it should preferably be saved/loaded from the
> device where TPL/SPL was booted from.
> 
> Personally I always run my devices with ENV_IS_NOWHERE, with standard
> boot and extlinux or efi as the preferred way to boot, I do not see why
> normal end-users with a single OS really have a need for a saved env,
> please educate me :-)

I am the maintainer of the meta-rockchip Yocto layer[1]. Yocto uses a
nifty tool called 'wic' to layout images (dos/gpt partitioning, optionally
formatting partitions, optionally installing things into those partitions)[2].
The partitioning layout that we follow is the one that is recommended by
Rockchip itself[3] with 2 exceptions:
- we don't hide any of the partitions from the partition table
- we've combined /boot into the root partition (for reasons I'll explain
  later)

Under the Rockchip partitioning, the U-Boot environment is stored in partition
5, at offset 0x0003.f800, and has a size of 0x0000.8000.

I don't own every Rockchip board, but I have a bunch of them (thanks to some
generous donations!). I've created a spreadsheet that lists the ones supported
by meta-rockchip and their environment variable U-Boot configurations
(locations, offsets, sizes). Most of them follow the Rockchip recommended
partitioning layout with regards to storing the environment. This set of
patches closes that gap, at least for the ones supported by meta-rockchip.

One of the things that I want to do next with meta-rockchip is to provide
an easy way for users to enable some sort of A/B OTA update strategy.
Currently, enabling an A/B update mechanism for any board (Rockchip or not)
is a non-trivial exercise. Every A/B update mechanism that I've looked at
requires (among other things) the bootloader to be able to store/retrieve
its environment from U-Boot itself (obviously) and also from Linux userspace
since it is the bootloader that ultimately boots from either the A or the B
partition. I'm specifically focused on rauc, but all the A/B update mechanisms
I've looked at have this same requirement.

Users who don't care for A/B updates can simply use meta-rockchip as-is, those
who want an A/B strategy would simply enable a setting or two in their Yocto
config and meta-rockchip would take care of the details, regardless of which
Rockchip board they're using.

I've combined /boot into the root partition since it makes A/B updates easier.
Otherwise in order to work it would actually be an Aboot+Aroot/Bboot+Broot
mechanism, which is clumsy. Also since U-Boot is stored in partition by
itself, the only thing in the /boot partition is the U-Boot boot mechanism
(boot script, extlinux, etc), the Linux kernel, and the DTB (or fitImage). In
general it's better to keep the kernel and the root filesystem in sync, so
having a separate /boot partition is clumsy for no gain.

The other nice thing about wic is that it allows us to store random data
(or filesystems) in the image as we're creating it for the first time. In
other words, I have a mechanism that allows me to create the initial/default
U-Boot environment during the build, I can add or remove variables from it
dynamically as part of my build process, generate the proper binary blob of
that environment (i.e. with checksum), and lay it out into partition 5 of the
generated image so that on first boot the environment is already setup with
whatever U-Boot needs plus any custom tweaks the user adds.

> 
> > 
> > The rockchip pattern is usually to have a standard config for all boards and it is
> > not stored anywhere.
> 
> Unfortunately lots of rockchip boards have blindly enabled ENV_IN_MMC
> and force it to use sd-card. However, before enabling same forced
> behavior on new boards I would recommend ensuring adding support for
> allowing env to follow same load order as FIT (spl-boot-order).

I was pretty certain the "forcing it to SDcard" was going to cause push back,
which is why I highlighted it in my commit message since I didn't want it to
sneak in accidentally. The feedback is exactly what I was hoping. I wasn't
aware there might be a way to dynamically store the environment based on the
wishes of the user, that would be great!

But ultimately I want to keep the environment on the boot device and make
sure they're not separated. I could have 2 SDcards on my desk: one could be a
regular non-A/B layout, and the other would have an A/B layout. Technically I
wouldn't really need an environment on the non-A/B card, but if it did have
one, it would need to be different from the environment of the SDcard that had
the A/B update layout.

On many Rockchip-based boards the eMMC board is every bit as optional as the
SDcard, so keeping the environment on the same medium as the boot is
necessary.

For the user-case of a single OS I agree that an environment is not required
to be stored. But more and more we're seeing users want an OTA strategy
(especially in commercial/production environments), and if the one they want
is A/B-based, then storing the environment is something that needs to work.
Even in a non-production environment, having an A/B update mechanism could be
useful in a board-farm testing environment: take last night's build, update
the board's "other" partition, reboot, and see if it works. If it doesn't,
fall back to the working one and try again.

Currently meta-rockchip assumes SDcard usage. I know that's a limitation and
is on my TODO list to address someday so users could easily choose between
one or the other.

In order to get A/B working out of the box for meta-rockchip, I could carry
all these patches locally and still make everything work the way I would like.
But most Rockchip-based boards seem to already support storing an environment
in CONFIG_ENV_IS_IN_MMC, it's just the default device CONFIG_SYS_MMC_ENV_DEV
that we're disagreeing on.

> Regards,
> Jonas
> 
> > 
> > Kever, Jonas, please correct me if I am wrong.
> > 
> > Eugen
> 

[1] https://layers.openembedded.org/layerindex/branch/master/layer/meta-rockchip/
[2] https://git.yoctoproject.org/meta-rockchip/tree/wic/rockchip.wks
[3] https://opensource.rock-chips.com/wiki_Partitions

Re: [PATCH] configs: rockchip: rock5a: enable environment

[Jonas Karlman]

On 2024-03-05 14:45, Trevor Woerner wrote:
> On Tue 2024-03-05 @ 10:17:10 AM, Jonas Karlman wrote:
>> Hi,
>>
>> On 2024-03-05 06:40, Eugen Hristev wrote:
>>> On 3/5/24 04:10, Trevor Woerner wrote:
>>>> Following the pattern of other Rockchip devices, enable the U-Boot
>>>> environment to be stored in MMC. This patch specifically assumes the
>>>> environment will be stored on the SDcard.
>>>>
>>>> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
>>>> ---
>>>>  configs/rock5a-rk3588s_defconfig | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
>>>> index a6471a519514..ac6411667d9a 100644
>>>> --- a/configs/rock5a-rk3588s_defconfig
>>>> +++ b/configs/rock5a-rk3588s_defconfig
>>>> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>>>  CONFIG_NR_DRAM_BANKS=2
>>>>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>>>>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
>>>> +CONFIG_ENV_SIZE=0x8000
>>>>  CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
>>>>  CONFIG_ROCKCHIP_RK3588=y
>>>>  CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>>>> @@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
>>>>  CONFIG_SPL_OF_CONTROL=y
>>>>  CONFIG_OF_LIVE=y
>>>>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>>>> +CONFIG_ENV_IS_IN_MMC=y
>>>> +CONFIG_SYS_MMC_ENV_DEV=1
>>>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>>>  CONFIG_SPL_REGMAP=y
>>>>  CONFIG_SPL_SYSCON=y
>>>
>>>
>>> Hi Trevor,
>>>
>>> What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash ?
>>
>> Agree, we should not blindly enable env and expect that it can be stored
>> on sd-card. If anything, it should preferably be saved/loaded from the
>> device where TPL/SPL was booted from.
>>
>> Personally I always run my devices with ENV_IS_NOWHERE, with standard
>> boot and extlinux or efi as the preferred way to boot, I do not see why
>> normal end-users with a single OS really have a need for a saved env,
>> please educate me :-)
> 
> I am the maintainer of the meta-rockchip Yocto layer[1]. Yocto uses a
> nifty tool called 'wic' to layout images (dos/gpt partitioning, optionally
> formatting partitions, optionally installing things into those partitions)[2].
> The partitioning layout that we follow is the one that is recommended by
> Rockchip itself[3] with 2 exceptions:
> - we don't hide any of the partitions from the partition table
> - we've combined /boot into the root partition (for reasons I'll explain
>   later)
> 
> Under the Rockchip partitioning, the U-Boot environment is stored in partition
> 5, at offset 0x0003.f800, and has a size of 0x0000.8000.

Not sure you should look too much at the Rockchip partitioning, not sure
it is something to promote for mainline Linux and U-Boot usage. The
partitions is not correct/relevant, especially for aarch64. For mainline
the following offsets are typically only used:

- 0x00008000: TPL+SPL - up to around 256+256 KiB
- 0x003F8000: optional U-Boot env
- 0x00800000: FIT with U-Boot proper + TF-A and/or OPTEE,
              or U-Boot proper in legacy image format
- 0x01000000+: free use

It is highly recommended to write the generated u-boot-rockchip.bin to
sector 0x40 of mmc to get all the U-Boot related offsets correct as
defined in board defconfig.

To me the traditional Rockchip partitioning scheme does not really fill
any purpose with mainline Linux and U-Boot, please enlighten me :-)

One thing that vendor U-Boot does that possible could be adopted for
mainline U-Boot is that it will locate FIT based on a GPT partition
named "uboot" and fallback to traditional sector 0x4000.
The offsets and size of traditional Rockchip partitioning scheme is no
longer that important for vendor U-Boot/Linux.

It is also possible to reclaim some of the wasted space by putting FIT
at a different location, e.g:

- 0x00008000: TPL+SPL - up to around 256+256 KiB
- 0x00088000: FIT with U-Boot proper + TF-A - up to 3520 KiB
- 0x003F8000: optional U-Boot env
- 0x00400000+: free use

> 
> I don't own every Rockchip board, but I have a bunch of them (thanks to some
> generous donations!). I've created a spreadsheet that lists the ones supported
> by meta-rockchip and their environment variable U-Boot configurations
> (locations, offsets, sizes). Most of them follow the Rockchip recommended
> partitioning layout with regards to storing the environment. This set of
> patches closes that gap, at least for the ones supported by meta-rockchip.
> 
> One of the things that I want to do next with meta-rockchip is to provide
> an easy way for users to enable some sort of A/B OTA update strategy.
> Currently, enabling an A/B update mechanism for any board (Rockchip or not)
> is a non-trivial exercise. Every A/B update mechanism that I've looked at
> requires (among other things) the bootloader to be able to store/retrieve
> its environment from U-Boot itself (obviously) and also from Linux userspace
> since it is the bootloader that ultimately boots from either the A or the B
> partition. I'm specifically focused on rauc, but all the A/B update mechanisms
> I've looked at have this same requirement.

The Boot Loader Specification [a] and Automatic Boot Assessment [b]
describe one alternative way that would not involve U-Boot env,
unfortunately U-Boot does not follow the Boot Loader Specification,
a bootflow I would like to see being implemented :-)

[a] https://uapi-group.org/specifications/specs/boot_loader_specification/
[b] https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

Also are you only focusing on A/B for the kernel/OS or or does that also
include a strategy for how to A/B update the bootloader itself?

For bootloader A/B the Rockchip BROM typically will try to find the IDB
from multiple locations, e.g. sector 0x40, 0x240, 0x440, 0x640 if I am
not mistaken. This could potentially be used to create two pairs of
TPL+SPL/env/FIT combo.

> 
> Users who don't care for A/B updates can simply use meta-rockchip as-is, those
> who want an A/B strategy would simply enable a setting or two in their Yocto
> config and meta-rockchip would take care of the details, regardless of which
> Rockchip board they're using.
> 
> I've combined /boot into the root partition since it makes A/B updates easier.
> Otherwise in order to work it would actually be an Aboot+Aroot/Bboot+Broot
> mechanism, which is clumsy. Also since U-Boot is stored in partition by
> itself, the only thing in the /boot partition is the U-Boot boot mechanism
> (boot script, extlinux, etc), the Linux kernel, and the DTB (or fitImage). In
> general it's better to keep the kernel and the root filesystem in sync, so
> having a separate /boot partition is clumsy for no gain.
> 
> The other nice thing about wic is that it allows us to store random data
> (or filesystems) in the image as we're creating it for the first time. In
> other words, I have a mechanism that allows me to create the initial/default
> U-Boot environment during the build, I can add or remove variables from it
> dynamically as part of my build process, generate the proper binary blob of
> that environment (i.e. with checksum), and lay it out into partition 5 of the
> generated image so that on first boot the environment is already setup with
> whatever U-Boot needs plus any custom tweaks the user adds.
> 
>>
>>>
>>> The rockchip pattern is usually to have a standard config for all boards and it is
>>> not stored anywhere.
>>
>> Unfortunately lots of rockchip boards have blindly enabled ENV_IN_MMC
>> and force it to use sd-card. However, before enabling same forced
>> behavior on new boards I would recommend ensuring adding support for
>> allowing env to follow same load order as FIT (spl-boot-order).
> 
> I was pretty certain the "forcing it to SDcard" was going to cause push back,
> which is why I highlighted it in my commit message since I didn't want it to
> sneak in accidentally. The feedback is exactly what I was hoping. I wasn't
> aware there might be a way to dynamically store the environment based on the
> wishes of the user, that would be great!
> 
> But ultimately I want to keep the environment on the boot device and make
> sure they're not separated. I could have 2 SDcards on my desk: one could be a
> regular non-A/B layout, and the other would have an A/B layout. Technically I
> wouldn't really need an environment on the non-A/B card, but if it did have
> one, it would need to be different from the environment of the SDcard that had
> the A/B update layout.
> 
> On many Rockchip-based boards the eMMC board is every bit as optional as the
> SDcard, so keeping the environment on the same medium as the boot is
> necessary.

I fully agree, keeping TPL+SPL/FIT/env on same media would be preferably,
with some code it should be possible. For emmc we could even get more
crazy and potentially store FIT+env in one of the two hw boot partitions.
BROM does not support booting from the boot partitions but we can make
SPL/U-Boot proper read from it.

> 
> For the user-case of a single OS I agree that an environment is not required
> to be stored. But more and more we're seeing users want an OTA strategy
> (especially in commercial/production environments), and if the one they want
> is A/B-based, then storing the environment is something that needs to work.
> Even in a non-production environment, having an A/B update mechanism could be
> useful in a board-farm testing environment: take last night's build, update
> the board's "other" partition, reboot, and see if it works. If it doesn't,
> fall back to the working one and try again.
> 
> Currently meta-rockchip assumes SDcard usage. I know that's a limitation and
> is on my TODO list to address someday so users could easily choose between
> one or the other.
> 
> In order to get A/B working out of the box for meta-rockchip, I could carry
> all these patches locally and still make everything work the way I would like.
> But most Rockchip-based boards seem to already support storing an environment
> in CONFIG_ENV_IS_IN_MMC, it's just the default device CONFIG_SYS_MMC_ENV_DEV
> that we're disagreeing on.

Most devices that has onboard SPI flash typically have ENV_IS_IN_SPI,
and two of the four boards affected by your patches comes with onboard
SPI flash. For those, 3A and 5B, it make more sense to enable env in SPI
if it is needed until automatic location selection have been implemented.

Regards,
Jonas

> 
>> Regards,
>> Jonas
>>
>>>
>>> Kever, Jonas, please correct me if I am wrong.
>>>
>>> Eugen
>>
> 
> [1] https://layers.openembedded.org/layerindex/branch/master/layer/meta-rockchip/
> [2] https://git.yoctoproject.org/meta-rockchip/tree/wic/rockchip.wks
> [3] https://opensource.rock-chips.com/wiki_Partitions

Re: [PATCH] configs: rockchip: rock5a: enable environment

[Kever Yang]

Hi Eugen,

On 2024/3/5 13:40, Eugen Hristev wrote:
> On 3/5/24 04:10, Trevor Woerner wrote:
>> Following the pattern of other Rockchip devices, enable the U-Boot
>> environment to be stored in MMC. This patch specifically assumes the
>> environment will be stored on the SDcard.
>>
>> Signed-off-by: Trevor Woerner<twoerner@gmail.com>
>> ---
>>   configs/rock5a-rk3588s_defconfig | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
>> index a6471a519514..ac6411667d9a 100644
>> --- a/configs/rock5a-rk3588s_defconfig
>> +++ b/configs/rock5a-rk3588s_defconfig
>> @@ -8,6 +8,7 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>   CONFIG_NR_DRAM_BANKS=2
>>   CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
>> +CONFIG_ENV_SIZE=0x8000
>>   CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a"
>>   CONFIG_ROCKCHIP_RK3588=y
>>   CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>> @@ -48,6 +49,8 @@ CONFIG_CMD_REGULATOR=y
>>   CONFIG_SPL_OF_CONTROL=y
>>   CONFIG_OF_LIVE=y
>>   CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>> +CONFIG_ENV_IS_IN_MMC=y
>> +CONFIG_SYS_MMC_ENV_DEV=1
>>   CONFIG_SPL_DM_SEQ_ALIAS=y
>>   CONFIG_SPL_REGMAP=y
>>   CONFIG_SPL_SYSCON=y
>
> Hi Trevor,
>
> What will happen if there is no Sd-Card, and we boot from eMMC or SPI flash ?
The U-Boot should boot correctly with default env, and  without any env 
from storage.

The env is used for U-Boot preoper, they should come from the same storage.

> The rockchip pattern is usually to have a standard config for all boards and it is
> not stored anywhere.

Do you mean rockchip vendor U-Boot? I think rockchip vendor U-Boot does 
not depends on the  env on storage,

it use default env for boot process and a vendor defined "vendor 
storage" for MAC/SN.


Thanks,

- Kever

>
> Kever, Jonas, please correct me if I am wrong.
>
> Eugen

[PATCH] configs: rockchip: rock5b: enable environment

[Trevor Woerner]

Following the pattern of other Rockchip devices, enable the U-Boot
environment to be stored in MMC. This patch specifically assumes the
environment will be stored on the SDcard.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 configs/rock5b-rk3588_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 0595325e8107..64a242003aa1 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -60,6 +60,8 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SPL_SYSCON=y
-- 
2.43.0.76.g1a87c842ece3

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Jonas Karlman]

Hi Trevor,

On 2024-03-05 03:10, Trevor Woerner wrote:
> Following the pattern of other Rockchip devices, enable the U-Boot
> environment to be stored in MMC. This patch specifically assumes the
> environment will be stored on the SDcard.

This board has SPI flash, so storing env in SPI flash is probably a
better default. However, preferably the env should be stored/loaded from
the same device that TPL/SPL was loaded from.

Regards,
Jonas

> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
>  configs/rock5b-rk3588_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
> index 0595325e8107..64a242003aa1 100644
> --- a/configs/rock5b-rk3588_defconfig
> +++ b/configs/rock5b-rk3588_defconfig
> @@ -60,6 +60,8 @@ CONFIG_CMD_REGULATOR=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIVE=y
>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_MMC_ENV_DEV=1
>  CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_SPL_SYSCON=y

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Christopher Obbard]

Hi Jonas & Trevor,

On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote:
> Hi Trevor,
> 
> On 2024-03-05 03:10, Trevor Woerner wrote:
> > Following the pattern of other Rockchip devices, enable the U-Boot
> > environment to be stored in MMC. This patch specifically assumes the
> > environment will be stored on the SDcard.
> 
> This board has SPI flash, so storing env in SPI flash is probably a
> better default.

I agree with that.

> However, preferably the env should be stored/loaded from
> the same device that TPL/SPL was loaded from.

Do you know if there is some mechanism in U-Boot to do this already ?

It could be useful to enable autodetection on many boards which can boot U-
Boot from either SPI flash / eMMC / SD card.


Cheers!

Chris

> 
> Regards,
> Jonas
> 
> > 
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> >  configs/rock5b-rk3588_defconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-
> > rk3588_defconfig
> > index 0595325e8107..64a242003aa1 100644
> > --- a/configs/rock5b-rk3588_defconfig
> > +++ b/configs/rock5b-rk3588_defconfig
> > @@ -60,6 +60,8 @@ CONFIG_CMD_REGULATOR=y
> >  CONFIG_SPL_OF_CONTROL=y
> >  CONFIG_OF_LIVE=y
> >  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
> > assigned-clock-rates assigned-clock-parents"
> > +CONFIG_ENV_IS_IN_MMC=y
> > +CONFIG_SYS_MMC_ENV_DEV=1
> >  CONFIG_SPL_DM_SEQ_ALIAS=y
> >  CONFIG_SPL_REGMAP=y
> >  CONFIG_SPL_SYSCON=y
> 

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Jonas Karlman]

Hi Christopher,

On 2024-03-05 10:36, Christopher Obbard wrote:
> Hi Jonas & Trevor,
> 
> On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote:
>> Hi Trevor,
>>
>> On 2024-03-05 03:10, Trevor Woerner wrote:
>>> Following the pattern of other Rockchip devices, enable the U-Boot
>>> environment to be stored in MMC. This patch specifically assumes the
>>> environment will be stored on the SDcard.
>>
>> This board has SPI flash, so storing env in SPI flash is probably a
>> better default.
> 
> I agree with that.
> 
>> However, preferably the env should be stored/loaded from
>> the same device that TPL/SPL was loaded from.
> 
> Do you know if there is some mechanism in U-Boot to do this already ?
> 
> It could be useful to enable autodetection on many boards which can boot U-
> Boot from either SPI flash / eMMC / SD card.
> 

I think it should be possible with a combo of env_get_location(),
arch_env_get_location() and mmc_get_env_dev().

board/theobroma-systems/common/common.c does something like this already,
other arch also have these functions defined, for inspiration.

Regards,
Jonas

> 
> Cheers!
> 
> Chris
> 
>>
>> Regards,
>> Jonas
>>
>>>
>>> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
>>> ---
>>>  configs/rock5b-rk3588_defconfig | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-
>>> rk3588_defconfig
>>> index 0595325e8107..64a242003aa1 100644
>>> --- a/configs/rock5b-rk3588_defconfig
>>> +++ b/configs/rock5b-rk3588_defconfig
>>> @@ -60,6 +60,8 @@ CONFIG_CMD_REGULATOR=y
>>>  CONFIG_SPL_OF_CONTROL=y
>>>  CONFIG_OF_LIVE=y
>>>  CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks
>>> assigned-clock-rates assigned-clock-parents"
>>> +CONFIG_ENV_IS_IN_MMC=y
>>> +CONFIG_SYS_MMC_ENV_DEV=1
>>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>>  CONFIG_SPL_REGMAP=y
>>>  CONFIG_SPL_SYSCON=y
>>

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Quentin Schulz]

Hi all,

On 3/5/24 10:36, Christopher Obbard wrote:
> [You don't often get email from chris.obbard@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Jonas & Trevor,
> 
> On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote:
>> Hi Trevor,
>>
>> On 2024-03-05 03:10, Trevor Woerner wrote:
>>> Following the pattern of other Rockchip devices, enable the U-Boot
>>> environment to be stored in MMC. This patch specifically assumes the
>>> environment will be stored on the SDcard.
>>
>> This board has SPI flash, so storing env in SPI flash is probably a
>> better default.
> 
> I agree with that.
> 
>> However, preferably the env should be stored/loaded from
>> the same device that TPL/SPL was loaded from.
> 
> Do you know if there is some mechanism in U-Boot to do this already ?
> 

We do this for our Theobroma boards, though we use the same device that 
U-Boot proper was loaded from, and not the one that TPL+SPL was loaded 
from but the logic could be more or less the same.

https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L92-L152

is what you need. The first function is to differentiate between SD card 
and eMMC, the second actually returns the **kind** of medium the 
environment is stored on (so MMC or SPI-flash for Theobroma boards).

Instead of 
https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L94-L95 
you probably want to use board_spl_was_booted_from().

Note that to you need the MMC and SPI controllers to be bound in U-Boot 
proper **before relocation** for this to work. c.f. 
https://lore.kernel.org/u-boot/20240221-jaguar-v3-15-1f256a82201b@theobroma-systems.com/

> It could be useful to enable autodetection on many boards which can boot U-
> Boot from either SPI flash / eMMC / SD card.
> 

There's been an attempt recently:

https://lore.kernel.org/u-boot/20240226011413.435713-2-benwolsieffer@gmail.com/

though only for the MMC part of the equation.

Cheers,
Quentin

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Jonas Karlman]

On 2024-03-05 11:11, Quentin Schulz wrote:
> Hi all,
> 
> On 3/5/24 10:36, Christopher Obbard wrote:
>> [You don't often get email from chris.obbard@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi Jonas & Trevor,
>>
>> On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote:
>>> Hi Trevor,
>>>
>>> On 2024-03-05 03:10, Trevor Woerner wrote:
>>>> Following the pattern of other Rockchip devices, enable the U-Boot
>>>> environment to be stored in MMC. This patch specifically assumes the
>>>> environment will be stored on the SDcard.
>>>
>>> This board has SPI flash, so storing env in SPI flash is probably a
>>> better default.
>>
>> I agree with that.
>>
>>> However, preferably the env should be stored/loaded from
>>> the same device that TPL/SPL was loaded from.
>>
>> Do you know if there is some mechanism in U-Boot to do this already ?
>>
> 
> We do this for our Theobroma boards, though we use the same device that 
> U-Boot proper was loaded from, and not the one that TPL+SPL was loaded 
> from but the logic could be more or less the same.

Good catch, same as U-Boot proper may be more accurate and what I was
expecting, I typically expect TPL+SPL and FIT to be loaded from same
media so may see them as interchangeably.

My normal expectation will be that if FIT cannot be loaded from
same-as-spl we are in some kind of fallback and/or recovery mode.

Maybe a u-boot,env-load-order prop, similar to u-boot,spl-boot-order,
could be an option? with support for similar options, same-as-spl and
same-as-fit/proper/boot or node refs.

> 
> https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L92-L152
> 
> is what you need. The first function is to differentiate between SD card 
> and eMMC, the second actually returns the **kind** of medium the 
> environment is stored on (so MMC or SPI-flash for Theobroma boards).
> 
> Instead of 
> https://source.denx.de/u-boot/u-boot/-/blob/master/board/theobroma-systems/common/common.c?ref_type=heads#L94-L95 
> you probably want to use board_spl_was_booted_from().
> 
> Note that to you need the MMC and SPI controllers to be bound in U-Boot 
> proper **before relocation** for this to work. c.f. 
> https://lore.kernel.org/u-boot/20240221-jaguar-v3-15-1f256a82201b@theobroma-systems.com/
> 
>> It could be useful to enable autodetection on many boards which can boot U-
>> Boot from either SPI flash / eMMC / SD card.
>>
> 
> There's been an attempt recently:
> 
> https://lore.kernel.org/u-boot/20240226011413.435713-2-benwolsieffer@gmail.com/
> 
> though only for the MMC part of the equation.

I thought I noticed something related last few days/weeks, did not
manage to find anything when I went looking for it :-)

Regards,
Jonas

> 
> Cheers,
> Quentin

Re: [PATCH] configs: rockchip: rock5b: enable environment

[Dragan Simic]

Hello all,

On 2024-03-05 10:36, Christopher Obbard wrote:
> On Tue, 2024-03-05 at 10:31 +0100, Jonas Karlman wrote:
>> On 2024-03-05 03:10, Trevor Woerner wrote:
>> > Following the pattern of other Rockchip devices, enable the U-Boot
>> > environment to be stored in MMC. This patch specifically assumes the
>> > environment will be stored on the SDcard.
>> 
>> This board has SPI flash, so storing env in SPI flash is probably a
>> better default.
> 
> I agree with that.
> 
>> However, preferably the env should be stored/loaded from
>> the same device that TPL/SPL was loaded from.
> 
> Do you know if there is some mechanism in U-Boot to do this already ?
> 
> It could be useful to enable autodetection on many boards which can 
> boot U-
> Boot from either SPI flash / eMMC / SD card.

I agree that doing this on all Rockchip boards should be the way to go, 
or
perhaps to use the device that the U-Boot proper was loaded from.

Moreover, it would, for example, allow a microSD card to be used as a 
rescue
boot media for the users to recover from a borked environment.

Re: [PATCH] configs: rockchip: rock-pi-s: enable environment

[Jonas Karlman]

Hi Trevor,

On 2024-03-05 03:10, Trevor Woerner wrote:
> Following the pattern of other Rockchip devices, enable the U-Boot environment
> to be stored in MMC. This patch specifically assumes the environment will be
> stored on the SDcard.

This board support optional emmc (sd nand), forcing env to sd-card does
not sound like a good idea, ideally the env is stored in the media where
TPL/SPL is running from.

Please note that booting from emmc is not working in current state, I
have an incoming series to improve support for this and other rk3308
boards. Hoping to have it on list later this week, see [1] for current
work-in-progress patches. It enables full support for usb otg/host, ums,
rockusb, emmc/sd nand, ethernet, ethaddr from serial#, rnd and fit
checksum validation on this board (tested on a v1.3 board).

[1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3308-2024.04

Regards,
Jonas

> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
>  configs/rock-pi-s-rk3308_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/rock-pi-s-rk3308_defconfig b/configs/rock-pi-s-rk3308_defconfig
> index 9908a4b4f457..af2cddcc2553 100644
> --- a/configs/rock-pi-s-rk3308_defconfig
> +++ b/configs/rock-pi-s-rk3308_defconfig
> @@ -54,7 +54,9 @@ CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_OF_LIVE=y
>  CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SYS_MMC_ENV_DEV=1
>  CONFIG_REGMAP=y
>  CONFIG_SYSCON=y
>  CONFIG_CLK=y