00:09 <apteryx> marex: seems it doesn't for some reason, on a raspberry pi 3 b: https://paste.debian.net/1264893/

00:10 <apteryx> the u-boot is built for arm64 (64-bit), and the kernel armhf (32bit)

00:49 <marex> well, Merry Christmas, good bye ATF :-)

08:38 <jkorsnes[m]> I need to pass an unsigned integer from spl to proper. it seems like global-data is reset. is HANDOFF + BLOBLIST the only option? it seems a bit much for this task

11:31 <apalos> Tartarus1: https://lore.kernel.org/u-boot/CAHUa44GJ5UUuSkKfU2C2erfUbgM7n9vuBjkHqEvtogVyorf+NA@mail.gmail.com/

11:31 <apalos> This was assigned to me on patchwork, want me to carry it over the TPM tree?

13:57 <Tartarus1> apalos: Yes, I guess I was wondering how much of the TEE related stuff I could hand over to you as well :)

13:58 <Tartarus1> jkorsnes: do any of the existing save_boot_params give you a hint?

14:10 <sylensky[m]> is the crc32 written into the file when executing saveenv when the env file is in fat/ext4 filesystem?

14:50 <rfs613> sylensky[m]: yes, it uses env_export() which adds the CRC. I believe this is true of all the backends.

14:57 <sylensky[m]> rfs613: saw that but i dont get it why the uboot console can read/write the environment but the userspace can not as fw_printenv is complaining about bad crc

14:58 <Tartarus1> sylensky: it's likely you didn't configure /etc/fw_env.conf right then

15:00 <rfs613> you beat me to it ;-)

15:10 <sylensky[m]> please correct me if iam wrong but its just the filelocation with its size like /dev/sda3/uboot.env0x0000 0x4000 ?

15:12 <Tartarus1> So, it should be, yes, but... lets see

15:14 <Tartarus1> This does remind me of another problem report

15:17 <Tartarus1> sylensky: one thing is you don't have redundant env enabled, right?

15:21 <Tartarus1> sylensky: But... I think you might have a real issue.

15:22 <Tartarus1> I can't find the original report, it was someone on a Pi

15:22 <Tartarus1> And they found the CRC wasn't in the expected place, with file based env

15:22 <Tartarus1> off by one perhaps it was

15:22 <Tartarus1> But their fix looked to break all the other use cases

15:23 <Tartarus1> As maybe the problem is really that the u-boot side isn't putting it in the file in the right spot

15:23 <sylensky[m]> Tom Rini: iam actually on a pi aswell.. and no i dont have redundant env enabled

15:24 <Tartarus1> OK, then yeah, I think it's that same problem

15:26 <sylensky[m]> is that true that it behaves the same when its in fat filesystem? atleast thats what i observed on my pi and additionally i read somewhere the ext4 env support is heavily based on the fat implementation

15:27 <apalos> Tartarus1: I can add myself as a maintainer along with Jens and carry those over the TPM tree

15:27 <apalos> I'll send an MR later today. This is straightforoward enough to be safe for a late -rc :)

15:27 <Tartarus1> apalos: OK, thanks!

15:28 <Tartarus1> sylensky: Yes

15:37 <sylensky[m]> Tom Rini: ok thanks! going to put that on draft and might deep dive on that next year :)

20:24 <MrSaturn> Hi all. I think I found a bug in the BTRFS implementation. I would love to get a second opinion though. With duplication enabled: In inode.c - read_extent_data will be passed a len, representing the length of the file. In there, __btrfs_map_block will resize length because duplication is enabled. When read_extent_data returns it will error out because the amount requested does not match the length read.

20:24 <MrSaturn> That is probably really confusing.

20:50 <MrSaturn> hrm, it looks like maybe it was recently fixed. hrm

21:15 <MrSaturn> No, I think it still exists: https://paste.debian.net/1264992/

21:16 <MrSaturn> Here is a little trace that shows the flow. I am not sure what the intention is.

21:17 <MrSaturn> notice if "read != len" it will error out after checking each mirror with -EIO.