Need assistance - fw_printenv cannot read environment

[Mitch Gaines]

Hi there,

I am looking for some assistance on this issue I am experiencing. Thank you in advance for your time on this.

Setup:

* Orange Pi Zero

* Yocto - Dunfell

* v0.3.1 of libubootenv

When I run `fw_printenv`, it returns the following:

    root@orange-pi-zero:~# fw_printenv

    Cannot read environment, using default

    Cannot read default environment from file

My fw_env.config looks like this:

    root@orange-pi-zero:~# cat /etc/fw_env.config

    /boot/uboot.env 0x0000  0x4000

* In regards to the above values for the uboot.env offset (0x0000) and the file length (0x4000), I ran a hexdump on my /boot partition (mmcblk0p1) and found it to be located at 0x488000. Though, when I modified the offset value to match the starting point on the partition and re-ran fw_printenv, it seemed to hang and not print anything. I'm not sure if I am even referencing this correctly which is likely why there's an issue with this.

My uboot.env does exist at /boot/uboot.env and is created in a boot script I have made.

My gut says that the fw_env.config is simply not pointing to the proper location of the uboot.env. The contents of the uboot.env are what I'd expect. Do you have any suggestions for next steps in troubleshooting this problem? Is my method of finding the offset of uboot.env correct?

Appreciate the help.

Thanks,

Mitch

[Mitch Gaines]

To follow up with some more information that might be useful (after doing some more research on my end):

root@orange-pi-zero:~# cat /proc/partitions 
major minor  #blocks  name

 179        0   31260672 mmcblk0
 179        1     512000 mmcblk0p1 #contains the following: uImage, boot.scr, 
u-boot-initial-env sun8i-h2-plus-orangepi-zero.dtb; additionally, my uboot.env 
is saved to this partition whenever the initial boot happens
 179        2     681575 mmcblk0p2 #rootfs_A
 179        3     681575 mmcblk0p3 #rootfs_B

With this in mind, I tried configuring my /etc/fw_env.config to the following:

root@orange-pi-zero:~# cat /etc/fw_env.config
/dev/mmcblk0p1 0x3BA000000      0x4000

Where the offset value = 31260672*512 = 16005464064 = 0x3BA000000. Also tried setting it to the following with no success:

root@orange-pi-zero:~# cat /etc/fw_env.config
/boot/uboot.env 0x3BA000000      0x4000

Something else that may more may not be relevant is my use of an SPL binary. My wks file looks like this (and is adapted from what linux-sunxi provided to have 2 root file systems):

# short-description: Create SD card image with a boot partition
# long-description:
# Create an image that can be written onto a SD card using dd for use
# with Allwinner arm (32-bit) SoC family
#
# The disk layout used is:
#  - --------------------------- -------------- --------------
# | | u-boot-sunxi-with-spl.bin |     boot     |    rootfs    |
#  - --------------------------- -------------- --------------
# ^ ^                           ^              ^              ^
# | |                           |              |              |
# 0 |                         2MiB  ${SUNXI_BOOT_SPACE}MiB  ${SUNXI_BOOT_SPACE}MiB + rootfs + IMAGE_EXTRA_SPACE
#   8KiB 
#

part u-boot --source rawcopy --sourceparams="file=${SPL_BINARY}" --ondisk mmcblk0 --no-table --align 8
part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 2048 --fixed-size 500
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs_A --align 2048 --size 512 
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs_B --align 2048 --size 512

Hope this provides more useful information. Really appreciate your time on this.

Thanks,

Mitch

[Mitch Gaines]

Some more findings on my end -

Before that though - this is the right place to be reaching out for libubootenv, right? Is anybody seeing this? The docs seemed to point here as opposed to opening an issue on Github. Please let me know if this is not the case 🙂

So, yocto seems to be generating the following files:

• u-boot-initial-env
• u-boot-initial-env-orange-pi-zero
• u-boot-initial-env-orange-pi-zero-2020.01-r0

However, they don't seem to be getting placed into my generated file-systems. Potentially an issue to resolve at another time. For the meantime, however, I have manually placed those generated files into the file system.

When I do that, running fw_printenv seems to only print out the first var that is set in uboot.env. See below:

root@orange-pi-zero:~# fw_printenv
BOOT_A_LEFT=3

I ran strace on fw_printenv and this is what I get:

openat(AT_FDCWD, "/etc/fw_env.config", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=30, ...}) = 0
read(3, "/boot/uboot.env 0x0000 0x4000\n", 4096) = 30
lstat64("/boot", {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
lstat64("/boot/uboot.env", {st_mode=S_IFREG|0755, st_size=131072, ...}) = 0
stat64("/boot/uboot.env", {st_mode=S_IFREG|0755, st_size=131072, ...}) = 0
openat(AT_FDCWD, "/boot/uboot.env", O_RDONLY) = 4
close(4)                                = 0
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/var/lock/fw_printenv.lock", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
flock(3, LOCK_EX)                       = 0
openat(AT_FDCWD, "/boot/uboot.env", O_RDONLY) = 4
read(4, "\3365\337`BOOT_A_LEFT=3\0\0OOT_B_LEFT=3\0"..., 16384) = 16384
close(4)                                = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x4, 0x40), ...}) = 0
ioctl(1, TCGETS, {B115200 opost isig icanon echo ...}) = 0
write(1, "BOOT_A_LEFT=3\n", 14BOOT_A_LEFT=3
)         = 14
flock(3, LOCK_UN)                       = 0
close(3)                                = 0
exit_group(0)                           = ?

I have fw_env.config set to the following and it seems to find the uboot.env file without issue:

root@orange-pi-zero:~# cat /etc/fw_env.config
/boot/uboot.env 0x0000 0x4000

Any help on this would be very much appreciated. Please let me know if there is a more appropriate location for me to open this issue!

Thanks,

Mitch

[Stefano Babic]

Hi Mitch,

On 14.06.21 20:06, Mitch Gaines wrote:
> Some more findings on my end -
>
> Before that though - this is the right place to be reaching out for
> libubootenv, right? Is anybody seeing this? The docs seemed to point
> here as opposed to opening an issue on Github. Please let me know if
> this is not the case 🙂
>

FYI: yes, this is the right place, but if nobody is using OrangePI, it
is required to check U-Boot sources to get where the environment is set.
And also to change sources, as I suspect no redundancy is set, and so
on. All of this requires too much time and it cannot be done for free.
Just a suggestion after reading fast your e-mails:

At first glance, the environment is simply set in a file and not as raw
data, and on VFAT filesystem, that is also not a good idea. Just to make
it working, you should set in fw_env.config to get a file instead of
offsets (look at original sources for Raspi for example), but do not use
it in a real project because it is not reliable enough.

Best regards,
Stefano Babic

> So, yocto seems to be generating the following files:
>

> *
> u-boot-initial-env
> *
> u-boot-initial-env-orange-pi-zero
> *

> u-boot-initial-env-orange-pi-zero-2020.01-r0
>
> However, they don't seem to be getting placed into my generated
> file-systems. Potentially an issue to resolve at another time. For the
> meantime, however, I have manually placed those generated files into the
> file system.
>
> When I do that, running fw_printenv seems to only print out the

> *first* var that is set in uboot.env. See below:

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/60DAB176-95F8-47B5-8D7E-BA1D3906AE81%40getmailspring.com
> <https://groups.google.com/d/msgid/swupdate/60DAB176-95F8-47B5-8D7E-BA1D3906AE81%40getmailspring.com?utm_medium=email&utm_source=footer>.


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Mitch Gaines]

Hi Stephano! Thanks for following up

FYI: yes, this is the right place, but if nobody is using OrangePI, it

is required to check U-Boot sources to get where the environment is set.

And also to change sources, as I suspect no redundancy is set, and so

on. All of this requires too much time and it cannot be done for free.

I understand - that makes sense. Wanted to be sure I wasn't reaching out to a group that was discontinued or something. Thanks for the response! I'll try to keep my questions more general, so as not to request obscene amounts of your time.

At first glance, the environment is simply set in a file and not as raw

data, and on VFAT filesystem, that is also not a good idea. Just to make

it working, you should set in fw_env.config to get a file instead of

offsets (look at original sources for Raspi for example), but do not use

it in a real project because it is not reliable enough.

Is what you're referring to here the use of /boot/uboot.env 0x0000 0x4000  versus /dev/mmcblk0p1 0x(offset) 0x(length) in the fw_env.config?

I seemed to find some success using the former. It was taken from a raspi example. Based on the stack trace I posted, it seems to find the file without issue using that. But, I cannot for the life of me figure out why it only seems to read the first variable in the file and not the others. I wonder if there's a character or something in there that is terminating the reading of the file. I have attached that file for reference.

So, I think we're past the issue of referencing the environment, but I could certainly be wrong. With this in mind, I'm not sure if this is something you could potentially assist with. I totally understand if not though.

Thanks,

Mitch

[Stefano Babic]

Hi Mitch,

On 15.06.21 15:25, Mitch Gaines wrote:
> Hi Stephano! Thanks for following up
>
> FYI: yes, this is the right place, but if nobody is using OrangePI, it
>
> is required to check U-Boot sources to get where the environment is set.
>
> And also to change sources, as I suspect no redundancy is set, and so
>
> on. All of this requires too much time and it cannot be done for free.
>
>
> I understand - that makes sense. Wanted to be sure I wasn't reaching out
> to a group that was discontinued or something. Thanks for the response!
> I'll try to keep my questions more general, so as not to request obscene
> amounts of your time.

Ok

>
> At first glance, the environment is simply set in a file and not as raw
> data, and on VFAT filesystem, that is also not a good idea. Just to make
> it working, you should set in fw_env.config to get a file instead of
> offsets (look at original sources for Raspi for example), but do not use
> it in a real project because it is not reliable enough.
>
>
> Is what you're referring to here the use of |/boot/uboot.env 0x0000
> 0x4000|  versus |/dev/mmcblk0p1 0x(offset) 0x(length)| in the
> fw_env.config?

Right

>
> I seemed to find /some/ success using the former.

Because the environment is in a file, and do not use in real project.

> It was taken from a
> raspi example.

And it works for Raspi, not for OrangePI. Quite surely 0x4000 is wrong,
you have to find the size of the environemnt on OrangePI (check in
U-Boot sources).

> Based on the stack trace I posted, it seems to find the
> file without issue using that. But, I cannot for the life of me figure
> out why it only seems to read the first variable in the file and not the
> others. I wonder if there's a character or something in there that is
> terminating the reading of the file. I have attached that file for
> reference.
>

> So, I /think/ we're past the issue of referencing the environment, but I

> could certainly be wrong. With this in mind, I'm not sure if this is
> something you could potentially assist with.

Potentially a lot of people can do here, practically we want all to be
paid for our time if it is not a nitpick. Anyway, I am sure you can find
yourself after checkin in U-Boot.

> I totally understand if not
> though.

Best regards,
Stefano Babic

[Mitch Gaines]

Thanks for the insight here, Stefano!

And it works for Raspi, not for OrangePI. Quite surely 0x4000 is wrong,

you have to find the size of the environemnt on OrangePI (check in

U-Boot sources).

This pointed me to the solution which, as you noted, was related the environment length specified in my fw_env.config.

In this instance, that value needed to be set to 0x20000 so my fw_env.config looks like as follows:

root@orange-pi-zero:~# cat /etc/fw_env.config 
/boot/uboot.env 0x0000  0x20000

Now that it is set like that, fw_printenv  works as expected.

However, I see that you are saying not to actually use this in a production project. What would be the better approach here? Pointing to a partition and using offsets? When I run saveenv in u-boot, it seems to generate the uboot.env file. If I am pointing to a partition+offset, how do I got about saving that environment using my u-boot script?

Thanks,

Mitch

[Stefano Babic]

Hi Mitch,

On 15.06.21 21:37, Mitch Gaines wrote:
> Thanks for the insight here, Stefano!
>
> And it works for Raspi, not for OrangePI. Quite surely 0x4000 is wrong,
> you have to find the size of the environemnt on OrangePI (check in
> U-Boot sources).
>
>
> This pointed me to the solution which, as you noted, was related the
> environment length specified in my fw_env.config.
>
> In this instance, that value needed to be set to 0x20000 so my
> fw_env.config looks like as follows:
> |
>
> root@orange-pi-zero:~# cat /etc/fw_env.config
> /boot/uboot.env 0x0000  0x20000
>
> |
> Now that it is set like that, |fw_printenv|  works as expected.
>

Fine.

> However, I see that you are saying not to actually use this in a
> production project. What would be the better approach here? Pointing to
> a partition and using offsets? When I run |saveenv| in u-boot, it seems
> to generate the uboot.env file. If I am pointing to a partition+offset,
> how do I got about saving that environment using my u-boot script?

I do not know which storage options the OranePI has. Anyway, with
environment in file, ths can happen:

- filesystem gets corrupted, board is bricked
- powercut during writing the environment, file truncated, board is bricked

U-Boot supports redundant environment. You should change U-Boot, move to
redundant environment, and put the env in a free space (own partition
with offset, for example).

> https://groups.google.com/d/msgid/swupdate/19479316-2A57-45AE-AE64-D233B7435545%40getmailspring.com
> <https://groups.google.com/d/msgid/swupdate/19479316-2A57-45AE-AE64-D233B7435545%40getmailspring.com?utm_medium=email&utm_source=footer>.