General issues regarding F2FS rootfs partition

[Grench]

I realize that F2FS is the latest darling disk format of the Linux world. However, living on this bleeding edge has some pretty serious limitations and drawbacks.

Installing the latest available-to-me OS image onto a 64GB SDXC card results in only being able to use/see the first 8GB of the card within the OS. Where we're using apt from Debian repositories for software installs, more space in the rootfs would be a good thing. I can foresee users installing to up to 1TB cards.

Where the frustration hits: Trying to resize or grow the F2FS partition to 'fill the card'. Yes, I figured out how to do it by soft deleting the partition, creating a new bigger partition, formatting to F2FS then accepting back in the original signature then migrating the F2FS. It is a completely hacky multiple tools needed command line mash of frustration. F2FS is not compatible yet with most of the mainline partition management tools - and it has been a couple of years. F2FS still feels like betaware. There are -no- tools available to shrink an F2FS to spin off to archive.

If the partition were EXT4, it would simple to copy / expand / grow / shrink the partition and could be done with a wide array of GUI based tools.

So - what is the underlying reason we're using F2FS instead of EXT4? Using F2FS removes flexibility and compatibility and feels like way more trouble than it is worth.

 

[daveshah]

Interestingly, I found that gparted was able to expand the f2fs partition fine, but for reasons almost certainly unrelated to f2fs, messed about with the partition table or boot stuff such that the OMAP5 was no longer able to boot from it, until I messed around with the partition in fdisk and restored the bootloader.

I still don't know exactly what went wrong, but I fear the problem is in the OMAP5 boot ROM rather than gparted.

Not really f2fs related, but until this has been recommended further I wouldn't recommend gparted for Pyra boot media.

 

[Grench]

Interestingly, I found that gparted was able to expand the f2fs partition fine, but for reasons almost certainly unrelated to f2fs, messed about with the partition table or boot stuff such that the OMAP5 was no longer able to boot from it, until I messed around with the partition in fdisk and restored the bootloader.

I still don't know exactly what went wrong, but I fear the problem is in the OMAP5 boot ROM rather than gparted.

Not really f2fs related, but until this has been recommended further I wouldn't recommend gparted for Pyra boot media.

Yes - I found out about Gparted and the Pyra not being happy together back when I first got my prototype. Gparted apparently edits bits on the bootloader on partition 1 even if it isn't supposed to be touching that partition?

 

[Grench]

It would be really nice if we could get the Pyra to play nicely with Gparted.

Here is another use case for tools like Gparted and anything but F2FS (F2FS can't shrink partitions):
1. Build and test out an image on the SDXC.
2. Boot from the eMMC.
3. Shrink the partitions on the SDXC.
4. Create a 2nd copy on the SDXC of the shrunken partitions.
4. Boot from the SDXC.
5. Delete the partitions on the eMMC (or internal microSDXC).
5. Copy the 2nd copy of the partitions on the SDXC over to the eMMC.
6. Expand / grow the partitions on the eMMC to your liking.

The same could be done against the internal microSDXC without having to remove it. Removing and re-inserting the microSDXC requires removing the SIM card - which is a pain if you're using a nano SIM in two size adapters to fit the socket. (The key is to put the SIM in the two nested adapters, set it gently on the flap, keep the flap level and turn the Pyra over in mid-air to seat it.) The fewer times of physically accessing the internal microSDXC card the better.

 

[levi]

I think all of the sdcards I've killed over the years have been done with gparted. Since I switched to using fdisk* I've had a lot more success.

* I'm not sure how much longer I can keep on using fdisk, since I think it's limited to MBR discs. That said I did install gdisk at some point, I just don't remember using it.

 

[ToastBucket]

F2FS is not required, but it is what @aTc uses for the root partition. ext4 could be used, but you will need to generate your own image to do that. It is scripted and not too difficult to flash an SD card. Flashing the eMMC is a bit more involved, I am working on integrating and documenting an easy method to do this into the bootloader. I believe F2FS was chosen to increase the lifespan of the internal eMMC.

Use this but modify the script to format your rootfs partition as ext4 instead of f2fs.

aTc / pyra-install · GitLab

PyraOS install script

dev.pyra-handheld.com

I have flashed my internal eMMC with @aTc's image (which has a 4GB rootfs partition) and expanded the filesystem to fill the remaining of the full 32GB. I partitioned my eMMC, flashed the rootfs and expanded the filesystem using resize.f2fs. It works quite well, but I have not investigated resizing F2FS partitions and I don't use gParted, so not familiar with its shortfalls.

 

[aTc]

All that stuff is a bit behind, since i changed the way images are built.
Currently working on getting everything back to the way i want it to function.
(installing to emmc, and automatically resizing sd cards)

 

[Grench]

All that stuff is a bit behind, since i changed the way images are built.
Currently working on getting everything back to the way i want it to function.
(installing to emmc, and automatically resizing sd cards)

Let me / us know when you get to the point where it makes sense to leverage a few beta testers?

I can probably live with F2FS if we can have a configuration setting that pops up to the end user to ask 'How much of the available XGB do you want this install to use?' I would be inclined to default to, 'all of it', though I understand that a lot of people still like having a separate /home partition.

Once things get stable and I can be confident that the Pyra isn't going to eat the card, I plan to drop in a 1TB microSDXC in the internal slot and use the eMMC as a 'backup OS'. They are still $233 a card, but - Terabyte.

 

[Silent-Hunter]

I wasn't aware the Pyra was using F2FS. Is it appropriately tuned to the eMMC characteristics? I heard you have to do that to make it work well.

 

[Askarus]

Once things get stable and I can be confident that the Pyra isn't going to eat the card, I plan to drop in a 1TB microSDXC in the internal slot and use the eMMC as a 'backup OS'. They are still $233 a card, but - Terabyte.

On my Prototype using the emmc felt a little more responsive than the SD-card.
So I plan to use it the other way round.
Emmc for day-to-day business and SD-card for other OS and experimental stuff.

 

[daveshah]

One annoyance at the moment is that to boot from the internal SD card, you need to remember to hold down a button when turning on or restarting.

The solution is to have an option where U-boot on eMMC load the kernel from and point the rootfs to the internal microSD card by default unless some other button isn't pressed (or even just rootfs).

 

[God Ginrai]

You can't just make it boot from eMMC whenever an internal microsd is not inserted? That seems like the most logical way for it to work.

-God Ginrai

 

[daveshah]

At a hardware level, fixed in the board wiring and logic, the first-stage boot order is essentially

left SD card if available and bootable --> internal uSD if L1 pressed --> eMMC

but U-boot on the eMMC can make its own decisions about where to load the kernel and rootfs from. Furthermore the LInux initrd itself can have a script to pick the rootfs location or load another kernel via kexec, with all the benefits of the Linux device driver system for a graphical menu, more device options, etc.

 

[levi]

I think ED's plan all along was to have a way to make the unit not depend on eMMC at all, because that has a limited lifespan and the idea was a duff unreadable eMMC wouldn't stop you using your unit.

It remains to be seen how much of an issue that limited lifespan actually is. My Pandora's NAND flash was still fine last time I was able to use it, and even my Atari Jaguar carts which claim to use flash for the high score table with only 10000 guaranteed writes are still all fine. And I guess it's something that could be sorted out later in any case.

 

[God Ginrai]

At a hardware level, fixed in the board wiring and logic, the first-stage boot order is essentially

left SD card if available and bootable --> internal uSD if L1 pressed --> eMMC

If the part I bolded wasn't there, this process would be perfect. Why the hell does it require L1 to be pressed here? And this is at the hardware level? Oy vey.

-God Ginrai

 

[daveshah]

Yes, that's just the way it was wired. Note that as the uSD and eMMC are the same boot device from the OMAP5 point of view; at best the alternative would be "uSD over eMMC if uSD inserted" rather than "uSD over eMMC if uSD bootable"

But as I said, a suitable U-boot config on the eMMC could implement any custom boot order for the kernel and rootfs etc.

Personally, for development, I am eschewing both the eMMC and uSD and booting from the left SD card slot (which always overrides those if it has a valid bootloader on it). This makes low-level development much easier when needing to try a new bootloader or kernel even if the device doesn't boot, while still leaving another another slot free for a "data" card.

 

[levi]

Okay, as long as the left sd card takes priority over the internal slot/eMMC there's a recovery path is the eMMC does ever become unreadable. You lose one of your external slots, but presumably we're looking at an old retro device by then anyway. I ran my Pandoras OS off my left SD card slot for a number of years, and it was never a problem for me. I guess it might be a problem if your camera used SD cards and you had an app like spotwell as a DBP on your apps card, but cameras that take SD cards are becoming something of a retro novelty already I guess.

 

[ToastBucket]

Yes, that's just the way it was wired. Note that as the uSD and eMMC are the same boot device from the OMAP5 point of view; at best the alternative would be "uSD over eMMC if uSD inserted" rather than "uSD over eMMC if uSD bootable"

But as I said, a suitable U-boot config on the eMMC could implement any custom boot order for the kernel and rootfs etc.

Personally, for development, I am eschewing both the eMMC and uSD and booting from the left SD card slot (which always overrides those if it has a valid bootloader on it). This makes low-level development much easier when needing to try a new bootloader or kernel even if the device doesn't boot, while still leaving another another slot free for a "data" card.

The way the bootloader is set up, the boot device could be adjusted without recompiling the bootloader. Before booting, it reads a uEnv.txt file that you can load onto the boot partition of the eMMC (or uSD if you hold L1). You can use this file to redefine the boot procedure including using the gpio command to set the switch to uSD and boot from that device rather than eMMC. I’ve got some plans to make this fancier, but they’ll take time so this is an easily customizable solution for now.

Currently I’m using all eMMC with fastboot right now which is real nice for development because I don’t have to pop the card in and out to reflash, it can all be done over USB rather quickly. I can even flash the SPL and Uboot with fastboot. Right now my current setup is running off eMMC with a 256M boot partition and rest of space (~31GiB) as rootfs. I then have a 128GB card with a backup boot partition and the rest of the space as an ext4 I mount as my home directory. This let’s me easily reflash my rootfs if I bork it in development but keep all my configurations and save game files intact. I also have a script in my home directory to reinstall all my tools when I need a rootfs reflash.

 

[daveshah]

Yeah, I still need to look at fastboot, it seems like a nice workflow. Usually I rsync/scp stuff across (this is useful for updating modules too) unless it doesn't boot that far.

 

[God Ginrai]

Yes, that's just the way it was wired. Note that as the uSD and eMMC are the same boot device from the OMAP5 point of view; at best the alternative would be "uSD over eMMC if uSD inserted" rather than "uSD over eMMC if uSD bootable"

Even that would be preferable.

But as I said, a suitable U-boot config on the eMMC could implement any custom boot order for the kernel and rootfs etc.

Personally, for development, I am eschewing both the eMMC and uSD and booting from the left SD card slot (which always overrides those if it has a valid bootloader on it). This makes low-level development much easier when needing to try a new bootloader or kernel even if the device doesn't boot, while still leaving another another slot free for a "data" card.

The issue with a u-boot config in the eMMC means that you're back to that L1 shit when your eMMC dies. The whole point of the internal microSD was to allow users to use that instead of the eMMC to allow the user to swap their default boot medium with little effort when it dies. Instead, it seems like the left SD slot is the only one that properly does this. But that's not preferable, because then for users whose eMMC dies, they have to either hold L1 on every boot or give up their left SD slot to run their OS.

-God Ginrai