From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sun, 27 Dec 2020 11:08:05 +0200
Subject: [PATCH v1] doc: README.distro: Special case with Windows
 formatted disk
In-Reply-To: <20201227002723.tsm4g5z5a2cu4v6n@pali>
References: <20200117104451.62417-1-andriy.shevchenko@linux.intel.com>
 <20201227002723.tsm4g5z5a2cu4v6n@pali>
Message-ID: <CAHp75Vf2EYdTYM+fZP6Hp83GxNRFpKmZs+79ZTsH8vuuXedS6Q@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Sunday, December 27, 2020, Pali Roh?r <pali@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@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.


-- 
With Best Regards,
Andy Shevchenko