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

[Tom Rini <trini@konsulko.com>]

On Mon, Dec 28, 2020 at 08:27:49PM +0200, Andy Shevchenko wrote:
> On Mon, Dec 28, 2020 at 06:50:39PM +0100, Pali Roh?r wrote:
> > On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> > > On Sunday, December 27, 2020, Pali Roh?r <pali@kernel.org> wrote:
> > > > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> 
> ...
> 
> > > > > +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.
> 
> On Linux you can use loop and offset, there is no hack needed.
> 
> > 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.
> 
> The case I got into has been achieved by very standard procedures. Hence it's
> kinda default behaviour in some cases and should be handled accordingly. The
> patch proposed here is to cover this in the U-Boot, because real fix has been
> rejected by maintainer (probably I failed to explain that). But this is still
> bug in U-Boot for such cases. And again, Linux has an offset option. I'm fine
> if this can be added to the fat* commands in the U-Boot.

Sorry, what is the real fix that was rejected again?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210129/698f79b9/attachment.sig>