[PATCH v1] doc: README.distro: Special case with Windows formatted disk

[Pali Rohár]

On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> On Sunday, December 27, 2020, Pali Rohár <pali at kernel.org> wrote:
> 
> > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> > > If someone wants to use shared (by installed OS) eMMC partition to
> > > the Windows to boot from, it's not possible due to U-Boot limitations.
> > >
> > > Describe this case and possible workaround.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> > > ---
> > >  doc/README.distro | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/doc/README.distro b/doc/README.distro
> > > index ab6e6f4e74..807a82c910 100644
> > > --- a/doc/README.distro
> > > +++ b/doc/README.distro
> > > @@ -405,3 +405,23 @@ of the boot environment and are not guaranteed to
> > exist or work in the same
> > >  way in future u-boot versions.  In particular the <device type>_boot
> > >  variables (e.g. mmc_boot, usb_boot) are a strictly internal
> > implementation
> > >  detail and must not be used as a public interface.
> > > +
> > > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > > +======================================================================
> > > +
> > > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > > +a disk via USB Mass Storage protocol.
> > > +
> > > +It may be useful to utilize that disk to copy bootable files from
> > > +Windows machine to the board in case someone doesn't want to erase
> > > +stock installation on it.
> > > +
> > > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > > +that disk as a whole, meaning that it creates a partition table on it
> > > +with requested (FAT) partition. As a result U-Boot may not see any
> > > +files on it due to nesting partition tables.
> > > +
> > > +The workaround may be in formatting the partition under Linux OS,
> > > +setting up a network connection between Linux OS and Windows 10 and
> > > +use it to copy files to the partition.
> >
> > There is a better way how to do it. You can format partition to FAT with
> > fake MBR table which reference to itself. Windows can correctly
> > recognize such disk because it has MBR table and do not care that
> > partition in MBR table starts at same offset as MBR table itself. And
> > FAT filesystem can be put on such partition because first sector (where
> > is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> > there. Also Linux does not have any issue to access such partition
> > because filesystem starts at offset zero (where it should be).
> >
> > FAT fs can be formatted with this fake MBR table by "mformat" tool which
> > should work also on Windows systems. "mformat" supports this feature for
> > a longer time but I do not remember how to activate it. Passing correct
> > arguments to "mformat" always took me lot of time.
> >
> > Or alternatively it can be formatted by "mkfs.fat" tool with option
> > --mbr=y but support for this option is not in any released version of
> > "mkfs.fat"
> >
> 
> 
> 
> While it’s a good idea, it’s not user friendly. The best option is to fix
> U-Boot to recognize nested fat disks. But yeah, we may describe this in
> U-Boot documentation at least.

I do not think that it is a good idea to recognize disks with nested MBR
tables in u-boot. Neither linux support it. On linux you can hack it via
device mapper kpartx or maybe also partx. But it is not something which
is used by default or which is user friendly, as you need to do it every
time when going to access such disk.

My "solution" (or workaround or hack) is just to use non-standard /
different arguments at the time when formatting disk and after this
one-time operation, disk is accessible on all common systems without any
future hacks. I think this is more user friendly.