09:20 <kwizart> Hello, I wonder what is the best way to switch between l4t/upstream userspaces for jetson-tx1 (using EFI). I've asked on the l4t forum as it's a downstream question, but maybe some have tips to share: https://forums.developer.nvidia.com/t/efi-support-for-jetson-tx1-and-running-upstream-kernel/187945 ?

11:14 <oldgalileo> Does anyone have the actual maximum rootfs size for the Jetson Nano eMMC (p3448-0002)

11:16 <oldgalileo> From what I can tell, if I were to subtract the size (in bytes) given in p3448-0000.common.conf for the BOOTPARTSIZE (4194304 bytes (?)) from the known size of the EMMC size (16GiB or 16*1024**3=17179869184 bytes), you get 17175674880 bytes or 15.996 GiB

11:43 <oldgalileo> The output from `fdisk` suggests there are two /dev/mmcblk0bootX devices with 4MiB each

11:57 <oldgalileo> https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fpart_config.html%23wwp104680

11:57 <oldgalileo> Okay, even going off of this

11:57 <oldgalileo> and getting the sum of every specified partition size, and not removing any of them

11:58 <oldgalileo> I get 530079744 bytes or about half a gig

12:07 <oldgalileo> Has Nvidia done any work yet with recovery images?

12:09 <oldgalileo> Can't really find any documentation around recovery images :(

13:59 <tambre> oldgalileo: Do you want something like: https://developer.ridgerun.com/wiki/index.php?title=How_to_Use_A/B_Filesystem_Redundancy_and_OTA_with_NVIDIA_Jetpack

14:21 <oldgalileo> timbre: Unfortunately not really. I have A/B switching working, but I'm surprised there isn't a concrete figure on how much size would actually be available if you, say, maxed out the partlabel==APP partition

14:21 <oldgalileo> tambre*

14:23 <oldgalileo> The docs say to check the <board>.common.conf file in the L4T directory, but for the Jetson Nano production that doesn't have very insightful figures, or at least is contradictory because the BOOTPARTSIZE is *kind of* correct (checked against `fdisk`, matches size) but doesn't mention that there are two sdmmc_boot disks apparently (mmcblk0boot0 and

14:23 <oldgalileo> mmcblk0boot1), and additionally in that file BOOTPARTSIZE is commented out and the value is assigned to the ROOTFSMAXSIZE which is very obviously not correct

14:26 <tambre> Why not just take the sise of /dev/mmcblk0 in bytes and subtract the sizes of all other partitions in the config?

14:27 <tambre> I've only worked with Xavier, so I'm not sure of any Nano-specific caveats.

14:28 <tambre> But I think that's what I did last time. At least my config contains "ROOTFSSIZE=$(((127908408832 / 4096) * 4096))", which is a bit less than the 127976603648B total size of /dev/mmcblk0 on one of my E3550 units.

14:30 <tambre> Well, I see three partitions. Subtracting their sizes and the padding from the total size roughly ends up with that number of bytes I have there.

14:31 <tambre> Seems I have some unused sectors at the end actually.

14:45 <oldgalileo> tambre: The nano has a bunch of partitions on the sdmmc_user area. I was interested in the recovery stuff (unrelated to A/B booting) just because by default there is I think around a 256MiB reserved for recovery image stuff

14:47 <oldgalileo> Even still, adding up all of those partitions gives me 530079744 bytes or 505MiB, which would, in my mind, indicate 15.5GiB remaining on the disk. So I was surprised that the prevailing Nvidia documentation is 14GiB for the APP partition.

14:48 <oldgalileo> That's a full tally of every partition in the documentation for the production nano. Again, the other part I'm wondering is where the mmcblk0boot devices comes in and why there are two of them 😕

14:54 <tambre> Partitions might have unused sectors before or between them. Add up the sectors and any padding before and between them to be more accurate.

14:55 <tambre> Also note that partition tables and such won't show up in the fdisk output.

15:57 <tagr_> oldgalileo:

15:59 <tagr_> oldgalileo: sorry for the late answer, but regarding those EMC table updates: the way that this works is that nvtboot (i.e. what you called TegrabootCPU) goes and parses the EMC tables from an in-memory DTB, trains the data on the memory and writes updated values back to that in-memory DTB

16:00 <tagr_> after that, when you boot upstream, the data is completely forgotten, because we can't usually use the downstream in-memory DTB to boot an upstream kernel

16:00 <tagr_> also, the upstream kernel doesn't understand the format that the downstream DTB uses to convey the EMC frequency table

22:35 <pgwipeout[m]> In that case could u-boot handle the transference/translation?