General issues regarding F2FS rootfs partition

[docbroke]

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.

That uEnv on eMMC will only work as long as eMMC is healthy. Once eMMC fails we will be back to holding L1 or sacrifice of left slot. That being said, I think ED spoiled us by giving too many boot options.
I actually liked idea of fastboot. At what level it is in boot sequence, does it replace uboot or it kicks before it and uboot works like smartphone recovery ? I am total noob Here, as I have never worked with uboot and my only experience of fastboot is from flashing roms on smartphone.

 

[Silent-Hunter]

So there's no way to change it to make the MicroSD the default if there's a bootable card in it?

 

[levi]

Not the way it's wired, as I'm reading it. The microSD card isn't connected to the system while the mux is in it's default postion, so it can't be looked at before you run something to flip the mux. And if that something is off some card e.g. in the left slot, you may as well just boot off it instead, as full sized cards are normally faster than muSD ones.

 

[daveshah]

At what level it is in boot sequence, does it replace uboot or it kicks before it and uboot works like smartphone recovery

fastboot is part of U-boot. The OMAP5 has its own internal USB boot with a custom protocol in ROM, but I don't know if anyone has tested it or if the Pyra is wired to use it.

The only time fastboot wouldn't be useable would be if U-boot itself got corrupted. In this case, recovery would still be easy by booting from the left SD card slot and running a recovery program - similar to a Pandora but with the OMAP5 being a lot less picky about which cards it boots from.

 

[docbroke]

fastboot is part of U-boot. The OMAP5 has its own internal USB boot with a custom protocol in ROM, but I don't know if anyone has tested it or if the Pyra is wired to use it.

The only time fastboot wouldn't be useable would be if U-boot itself got corrupted. In this case, recovery would still be easy by booting from the left SD card slot and running a recovery program - similar to a Pandora but with the OMAP5 being a lot less picky about which cards it boots from.

Can we connect pyra with laptop usb otg port and run "fastboot flash something something?", just like with android dumbphones ?

 

[daveshah]

I would presume so, Toast is working on it so he will know the details.

 

[Phlyra]

fastboot is part of U-boot. The OMAP5 has its own internal USB boot with a custom protocol in ROM, but I don't know if anyone has tested it or if the Pyra is wired to use it.

The only time fastboot wouldn't be useable would be if U-boot itself got corrupted. In this case, recovery would still be easy by booting from the left SD card slot and running a recovery program - similar to a Pandora but with the OMAP5 being a lot less picky about which cards it boots from.

Oooh internal USB boot would be great! If we could use it, I doubt there would be space for something like the SanDisk Extreme Pro or Ultra USB sticks but maybe something like the Cruzer Fit?
Bit off topic but been trying (and failing, spectacularly) to get the Pi-Top [3] and CEED hubs’ internal USB ports to work so I can launch PINN NOOBS from there and free up space on the RPi4’s USB ports...

 

[levi]

fastboot is part of U-boot. The OMAP5 has its own internal USB boot with a custom protocol in ROM, but I don't know if anyone has tested it or if the Pyra is wired to use it.

Oh, I thought it was the stuff in the OMAP5's internal rom/flash that looked at the left slot for something to boot. I think that was the way it worked on Pandora with it's OMAP3 derivatives, but it's fair to say that I never really got a great fix on what that was doing to boot; it seemed to have too many steps in it for starters.

 

[daveshah]

It is the OMAP5's internal ROM that looks at the left slot - that's not related to fastboot, which is a mechanism for flashing the eMMC over USB that is part of U-boot (in this case)

 

[levi]

Oh, sorry. I misinterpreted what 'it' was in 'tested it'.

 

[ToastBucket]

Can we connect pyra with laptop usb otg port and run "fastboot flash something something?", just like with android dumbphones ?

Yep. The eMMC needs to be partitioned already however.

 

[Grench]

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).

Having to press L1 at power on to boot from the internal microSDXC is not an issue - it is a feature.

When I pick up my Pyra to start it, I know to press that shoulder button to get to the OS I want from the microSDXC.
If someone else picks it up, they get the OS on the eMMC and the microSDXC is effectively hidden.

It is not annoying to have to hold a shoulder button. It is more of a 'security feature'.

I have fiddled around a bit with booting from the internal microSDXC. Yes, the eMMC is -marginally- faster to boot from. The internal microSDXC actually feels a bit faster than the left SDXC slot. At some point there will likely be a 100+ page thread about different media and how it behaves in the different slots and the subtleties of benchmarks against all of them.

 

[God Ginrai]

Having to press L1 at power on to boot from the internal microSDXC is not an issue - it is a feature.

When I pick up my Pyra to start it, I know to press that shoulder button to get to the OS I want from the microSDXC.
If someone else picks it up, they get the OS on the eMMC and the microSDXC is effectively hidden.

It is not annoying to have to hold a shoulder button. It is more of a 'security feature'.

I have fiddled around a bit with booting from the internal microSDXC. Yes, the eMMC is -marginally- faster to boot from. The internal microSDXC actually feels a bit faster than the left SDXC slot. At some point there will likely be a 100+ page thread about different media and how it behaves in the different slots and the subtleties of benchmarks against all of them.

That's sophistry. It is as much a feature as "delay slots" are. It is a detriment to a standard expected use of the device and can lead to future issues and annoyances. And there is nothing about that that makes it more secure, given that you can already boot from the left SD without having to hold the L1 button, which means that any attack vector that this would avoid exists for the left SD slot.

-God Ginrai

 

[Grench]

That's sophistry. It is as much a feature as "delay slots" are. It is a detriment to a standard expected use of the device and can lead to future issues and annoyances. And there is nothing about that that makes it more secure, given that you can already boot from the left SD without having to hold the L1 button, which means that any attack vector that this would avoid exists for the left SD slot.

-God Ginrai

The microSDXC slot is straight up invisible to the unit if booted from the left SDXC slot or the eMMC. (At least for now.) It only exists IF the unit is booted with the left shoulder pressed. (At least for now.)

I still say that it is a feature, at least up until the time when a driver is released that can dynamically switch the lines between the eMMC and the internal microSDXC slot. Until then it is a bit of security through obscurity.

 

[God Ginrai]

Until then it is a bit of security through obscurity.

But it is in no way security. As I mentioned, you can boot from the left SD slot without holding L1, which means that any security issue that the microSD slot might have had exists with the quite obvious left SD slot.

The requirement to hold L1 is not a feature. It's a bad decision that should never have been part of the design.

-God Ginrai

 

[ToastBucket]

Unfortunately we’re limited in hardware to this mechanism. There aren’t enough MMC host ports on the OMAP5 to support all 4 slots directly (one is used by the WiFi chip). Therefore one slot needs to be muxed in order to support both eMMC and uSD. I agree it’s a bit annoying, but there’s not really another way to support booting from one of the muxed ports. I definitely agree it is not a security feature. Obscurity is not security.

 

[God Ginrai]

Unfortunately we’re limited in hardware to this mechanism. There aren’t enough MMC host ports on the OMAP5 to support all 4 slots directly (one is used by the WiFi chip). Therefore one slot needs to be muxed in order to support both eMMC and uSD. I agree it’s a bit annoying, but there’s not really another way to support booting from one of the muxed ports. I definitely agree it is not a security feature. Obscurity is not security.

I see what you mean. However, could it not have been possible for the hardware to detect an inserted card and signal the mux automatically based on its presence? Since you can only use one or the other, it would make sense to assume that if you have a card in the microSD slot, that you intend to use it.

-God Ginrai

 

[theredbaron]

I see what you mean. However, could it not have been possible for the hardware to detect an inserted card and signal the mux automatically based on its presence? Since you can only use one or the other, it would make sense to assume that if you have a card in the microSD slot, that you intend to use it.

-God Ginrai

I disagree. It is good for dualbooting too. Emmc is the main OS, and microsd could be a testing os, or maybe Android, bsd, etc. Thus, if it autodetects, and boots, that negates it. Unless you have a shortcut to bypass, then we are back into the same boat.

Sent from my H3123 using Tapatalk

 

[ToastBucket]

I see what you mean. However, could it not have been possible for the hardware to detect an inserted card and signal the mux automatically based on its presence? Since you can only use one or the other, it would make sense to assume that if you have a card in the microSD slot, that you intend to use it.

-God Ginrai

If the hardware autodetects and chooses, the behavior is simpler, but less flexible. This gives more options. Plus, as the bootloader is open source and easily customizable without building it or reflashing it, you can always put the bootloader on the eMMC and have it boot whatever medium you want. You could also have it select which medium based on which key is pressed at boot (once I write a UBoot driver for the keyboard).

I definitely agree that it is kind of annoying and I personally choose not to use it, but there are some people that are a fan of this setup.

 

[Grench]

I disagree. It is good for dualbooting too. Emmc is the main OS, and microsd could be a testing os, or maybe Android, bsd, etc. Thus, if it autodetects, and boots, that negates it. Unless you have a shortcut to bypass, then we are back into the same boat.

Sent from my H3123 using Tapatalk

I actually plan to, once we have a 'stable' OS and bootloader, do just the opposite of what you describe.

The internal eMMC will have a full OS with utilities and whatnot on it.

For regular use, I'll hold a shoulder button and boot into an internal 1TB microSDXC card. I have done some initial testing of this (using a 64GB microSDXC card) and it works.

For right now, though, nearly everyone is booting from the left SDXC slot simply for convenience of swapping out the OS frequently.

From what I was able to tell on my non-scientific-seat-of-pants-mess-around-experiment, the internal microSDXC boots faster than the left SDXC slot. The eMMC is of course faster than both, but not by enough to really make a material difference in usage. I'll simply be sacrificing a small bit of speed for a boatload more active internal storage. Having to press a shoulder button during boot to get that additional storage is nothing.